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

[marvin42x]

@ 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]

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.

[UlrichC]

Ist <var =20 \> wirklich xml konform ich kenne nur das <Name>Wert</Name> und das ist heftig mehr.

Jo klar fast *knirsch shit* ,
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

[ragnar]

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

[UlrichC]

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

[ragnar]

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]

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

[PicNick]

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

[UlrichC]

@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]

@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ß