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

[marvin42x]

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/rea...ction=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 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.

[PicNick]

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]

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.

[PicNick]

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/elect...rover/mars.htm

https://www.roboternetz.de/phpBB2/ze...ight=marsrover

Da war natürlich die Kommunikation eher in deinem Sinne beschaffen.

Ich werd mir mal die smirs-Sache genauer anschauen.

[marvin42x]

Noch ein paar Quellen konkretisiert:
Hier bekommt man das smirs Protokoll:
http://www.mindrobots.de/cgi-bin/rea...name=&session=
als PDF runter geladen.
Hier bekommt man das Visual Basic Testmodul mit Quellcode:
http://www.mindrobots.de/cgi-bin/rea...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?

[PicNick]

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]

Das muss man runterladen
Visual Basic 2005 Express Edition
http://www.microsoft.com/germany/msd...s/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?

[PicNick]

..'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]

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ß

[PicNick]

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.