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

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

@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

@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

Zitat:

---

Zitat von marvin42x

@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

Zitat:

---

Zitat von Johannes

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.

Zitat:

---

Zitat von NumberFive

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.

Zitat:

---

Zitat von NumberFive

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.

Zitat:

---

Zitat von NumberFive

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/electroni...rover/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/in...#Byte-Stuffing

Man hört sich !