Archiv verlassen und diese Seite im Standarddesign anzeigen : Standart PC Software für Mobile Roboter
NumberFive
10.06.2004, 10:26
Hallo Leute,
habe mal ne fragen wenn dieses Forum schon eine Standart Platine für robter
entwickelt hat. Könnten wir doch auch ein Standart software oder nicht ?
Ich würde sie shreiben wollen natürlich nicht alleine aber in gemeinschaft schon.
Und so stelle ich mir das Teilt vor: Auf dem robi gibt es ein PC der unter
Win200 läuft. Es gibt ein Miro controller der mit dem PC Kommuniziert (RS232). Als add on gibt es ein tcp verbindung zu Control Center (Zweiter PC)
das könnte man leicht über WLan machen. Eine MySql db ist das gehirn des robis. Der ablauf im Prggramm kann jeder slbst bestimmen da der Ablauf in der datenbank liegt. Der Controller ist egal da serial nun mal fast alle können.
Also Interesse ? dann kräftit Posten.
Es gibt Teile dieser Software schon ich erzäle nix was nicht zu programmieren währe. An alle die menen nicht programmieren zu können
Auch interresse äussern ich brauche für meinen Robi noch hard von der ich kein Ahnung habe.
Gruß
Hallo Number Five!
Klingt sehr interessant, was du da vor hast.
In welcher Programmiersprache möchstest du das ganze realisieren? Ich würde etwas plattformunabhängiges vorschlagen, so dass das Programm evtl auch auf Linux laufen würde.
Was soll das Programm alles verarbeiten / steuern? Was macht der uC?
Ich würde mir das im Moment so vorstellen:
Der uC tastet mittels Sensoren die Umgebung ab. In der Datenbank kann man dann (mit einer schönen Benutzeroberfläche) einen Sensor hinzufügen, seine Position am Roboter angeben und ihm eine Adresse zuweisen. Dieser Sensor wird dann vom uC eingelesen und von Programm über die Adresse abgefragt.
Ebenso kann das Programm Steuerbefehle geben (also die Motoren steuern).
Dann kann man in die Datenbank evtl. Scripts programmieren, in denen man fertige Ausweichmanöver, bzw. Suchmanöver (z.B. für Lichtsuche) einspeichert.
Grüße
Flite
NumberFive
10.06.2004, 11:48
Hallo Flite,
na so ähnlich war es gemeint.
Es gibt 3 Programme:
Den Konfigurator der schreib die Konfig in die Datenbank.
Die Robotcontroll die die Config liest und den Controller abfragen und so weiter. Und den Monitor der über WLAn mit dem Roboter kommuniziert.
Die Funktion des Cotroller hast du richtig verstanden so war das gemeint.
Weiteteil wohlte ich in C++ schreiben da ich da schon ein bisschen was fertig habe. Das mit de plattfrom unabhängigkeit wird wohl nicht gehen da
wir zu dicht an die Hardware müssen um schnell genug zu sein. aber Es steht natürlich jedem frei die C++ Codes nach Linux zu portieren.
Und noch ein klares statment java kommt nicht in betracht und dot.net auch nett. Den configurator und den Monitor könnte man in delphi shreiben
da hat man das mit der Oberfläche leichter. Ober wenn es sein muß in VB aber dann VB 6.0. Was ich bei mir noch rein mache ich ein Programm zu analysiren des Viedeo bildes. Das kann dann sein Erkennise auch an dier RobotControl weitergeben.
NumberFive
10.06.2004, 11:57
nachtrag:
wo die Sensoren sitzen ist für das prg nicht wichtig da die ablaufstuerung(script) sagt was er tut wenn das un das kommt alle sensoren bekommen ein nummer (1-254) und werte bereicht von 0-255 das sollte nach mein dücken reichen. eben so die Aktoren.
So seid fünf minuten läuft mein AVR jetzt kann ich weiter testen
Gruß
Johannes
10.06.2004, 16:26
Moin Numberfive,
hast du dir schon mal meine Jufo-Arbeit runtergeladen? Ich habe so etwas ähnliches programmiert und werde demnächst die nächste Version starten.
Was mir vorschwebt: Eine Software, mit der es möglich ist, verschiedenste Hardwarekomponenten zu verknüfen. Das bedeutet: Man kann einen Roboter mittels eines Treibers, der speziell geschrieben werden muss (aber standardtreibver sind natürlich auch denkbar) in die Software einbinden.
Der Treiber kann nun Datenbereiche (z.B. Variablen) anmelden. Über diese Variablen kann dann die Software Daten von dem Roboter bekommen und ihm schicken.
Nun ist es mölglich, Beziehungen zwischen diesen Variablen zu setzten. Es gibt eine Scriptsprache, in der Funktionen definiert werden können, die ausgeführt werden, wenn sich beispielsweise eine Variable ändert. In diesem Fall kann dann das Script eine Variable einer anderen Hardwarekomponente ändern. Als Beispiel könnten dann so Roboter wissen, wo die anderen gerade sind, etc.
Die Software bietet weiterhin die Möglichkeit, Daten des Roboters anzuzeigen. Diese Anzeigemöglichkeiten werden als Plugins eingebunden, sodass man sich auch selbst ein spezielles Anzeigefeld programmieren kann. Diese Felder können dann mit Variablen verbunden werden. Natürlich können solche Plugins auch Variablen verändern und nicht nur anzeigen.
Dieses Problem habe ich mit ActiveX-DLLs gelöst. Bei der anmeldung wird dem Plugin ein Objekt übergeben, mit dem auf die Daten der Software und somit auch auf die Daten der eingebundenen Hardware zugegriffen werden kann.
Das alles funktioniert bei mir ganz gut, ich habe es mit Visual Basic geschrieben. Leider, und deshalb werden wir wohl nicht zusammenarbeiten könne, will nun die neue Software in JAVA schreiben. Auch ich wäre ein einem Gemeinschaftsprojekt interessiert.
Der zweite Schritt wäre dann eine Software für den Roboter selber. Du weißt, dass ich ja auch auf meinem nächsten Roboter einen PC installieren will. Vielleicht kann aber auch eine einzige Software diese ganzen Dinge abdecken, je nachdem, welche Plugins registriert werden. Die Roboter-Software bräuchte ja keine Anzeigeelemente, die PC-Software aber vielleicht schon.
Naja, vielleicht können wir ja wenigstens Ideen austauschen. Aber ich hatte vor, einige Funktionen auch mit C++ zu schreiben, gerade die Dinge mit den Plugins. Aber die Grundstruktur wäre schon ganz gut gelöst mit Java, besonders die grafischen oberflächen. Die C++-Routinben könnte man dann ja für mehrere Systeme kompillieren, oder erst einmal bei Windows bleiben.
Aber auf jedenfall ne interessante Diskussion, besonders weil ich sie schon vor kurzem selbst aufmachen wollte.
Schaut mal in meine Arbeit, ganz hinten bei "Control Desk":
http://www.mindrobots.de -> zum Download runterscrollen.
Gruß
Johannes
Johannes
10.06.2004, 16:30
P.S. Ich lege bei so einer Software großen Wert auf Konfigurationsmöglichkeiten und offenen Schnittstellen. Was pezielles kann keiner gebrauchen. Das Verhalten des Roboters sollte schon durch eigenen Quellcode festgelegt werden können. Die Software sollte nur als Unterstützung dienen und einfach zu verwenden sein (auch von der programmiertechnischen Einbindung eigener Erweiterunge).
NumberFive
10.06.2004, 16:30
Hallo Status bericht:
Folder Test aufbau ist realiesiert:
Termil VT100 macht den controller mit 38600 Baud.
SensorCatcher kümmert sich um die verabeitung der serialen daten
Daten format AXXE A SensorNummer SensorValue E
MessageCatcher ist per Com mit Sensorcatcher verbunden.
MessagesCatcher hat folgende Funktionen:
Sprachausgabe am PC Lautsprecher
Lenbensüberwachung so weit möglich (Rest und rechner neu start fehlt noch)
Verbindung zu Mysql Datenbank
Programm interpreter
Der Programm Interpreter wird jedes mal auf gerufen und durch läuft das programm wenn neu sensor daten an fallen. Auf die Sensor daten kann man per variable zu greifen.
Anbei nun das programm das interpretiert werden kann:
insert into PrgCode (RunningNumber,Code) values ( 0,'IF SENSOR01 = 01');
insert into PrgCode (RunningNumber,Code) values ( 1,'Trace war gleich');
insert into PrgCode (RunningNumber,Code) values ( 2,'ELSE');
insert into PrgCode (RunningNumber,Code) values ( 3,'Trace war nicht gleich');
insert into PrgCode (RunningNumber,Code) values ( 4,'ENDIF');
insert into PrgCode (RunningNumber,Code) values ( 5,'IF SENSOR53 = 53');
insert into PrgCode (RunningNumber,Code) values ( 6,'Trace war gleich');
insert into PrgCode (RunningNumber,Code) values ( 7,'SendMessage SensorWatch Test');
insert into PrgCode (RunningNumber,Code) values ( 8,'ELSE');
insert into PrgCode (RunningNumber,Code) values ( 9,'Trace war nicht gleich');
insert into PrgCode (RunningNumber,Code) values (10,'ENDIF');
insert into PrgCode (RunningNumber,Code) values (11,'Trace vor ende');
insert into PrgCode (RunningNumber,Code) values (12,'END');
NumberFive
10.06.2004, 16:51
Hallo Johannes,
ich mag halt kein java aber was heist das schon in unserem fall.
Das jedemen zu programmieren gibt. Nein dein arbeit habe ich nocht nicht gelesen war aber auch unterverschluß. Aber warum willt du auf java gehen ?
Allso irgend macht man schell prg als in delphi wenn man ein oberfläschen brauch. Mal ne frage wie komme ich von java aus an andere dinge
gibt es com oder dll aufrufe ?
Aber was du da beschreibst kann mein teil doch schon fast.
Ich habe zur zeit drei EXE SensorCatch, MessageCatcher, RoboCam
Master ist MessageCatch der ein Com interface zu verfügung stellt.
An diesem Meldet Sich so die Cam wie Auch der SensorCatcher an
DAs Interface ist sehr small hat nur Zwei Events Halt und MsgOut
Und drein funktionen Connect MsgIn und Trace
Im MsgIn oder MsgOut wird immer ein BSTR durch geben der So aussieht
MSG|ALIVE
MSG|DATA|Test
ACTION|MOTIONDETECT|
das sind beispiele
das mit den Addon's ist noch eine Idee
Aber jetzt werde ich erstmal dein Arbeit lesen
Gruß
Johannes
10.06.2004, 17:20
Moin,
schau die mal meine Arbeit an. Wir müssen erst einmal auf den selben Nenner kommen. Bei mir ist es so, dass ich noch keine konkrete Anwendung vor Augen habe, sondern nur Ideen, was man gebrauchen könnte.
Mit Java kann man nicht auf dlls zugreifen. Das sind halt Sachen, die es nur bei Windows gibt. Aber Java kann mit C++-Code kommunizieren. Mit Java könnte man dann die Oberfläche, also die gesamte Benutzerschnittstelle machen. Der große Vorteil wäre, dass man dann auch die Java-Plugins auf verschiedenen Plattformen verwenden könnte. Man müsste dann nicht zwischen den verschiedenen Betriebsystemen einen Struch ziehen. Nur die Grundsoftware wäre mit den C++-Routinen speziell, was aber nicht so problematisch wäre.
Aber man müsste die Oberfläche nur einmal machen.
Ich programmiere schon lange mit Visual Basic und möchte mich nun von WYSIWYG trennen. Aufwendige Sachen sind einfach schwer zu verwalten, unübersichtlich und eingeschränkt. Ich bin mir da mit Java sehr sicher.
Wenn wir zusammenkommen und eventuell sich noch ein paar Leute finden, dann könnten wir ein Gesamtschema erstellen. Da wir ja schon Erfahrungen mit den Sachen haben (schließlich habe ich schonmal so eine Software geschrieben und du bist ja auch gut dabei) würden wir bestimmt etwas Gutes zu Stande bringen.
Gruß
Johannes
Johannes
10.06.2004, 17:22
Noch etwas zur meiner momantanen Software (Control Desk): Da gibt es nur die Möglichkeit der Variablen, Daten auszutauschen. Bei einer eventuellen neuen Version würde ich einen Gateway-Kanal vorschlagen, den alle eingebundenen Komponenten abfragen. So wäre zum Beispiel eine Fernsteuerung wesentlich einfacher zu realisieren.
Gruß
Johannes
NumberFive
10.06.2004, 18:30
Hallo Johannes,
So jetzt habe ich deine Arbeit das erste mal durch und habe sie mir aus gedruckt. Werde sie sich noch eins zwei mal lesen müssen bis alles bis ins kleinste vertsanden habe aber das wird schon. Mal grundsätzlich habe ich auch ein großßes interesse mit dir zusammen zu arbeiten. Druch die
Verwendung von Com braucht ich in mein konzept nicht zu pollen
da ich event habe. das hei wenn jemand das möchte kann er es so fort weitergeben. es so gar in weitenteil gethreaet so das kein behinderungen auftreten. Was ich vor hin ver gessen habe die Tcp verbindung zum Control PC gibt es auch schon.
Nur mal ganz ehrlich ich finde es sehr schwer das alles hier rüber zu bringen aber ich werde es weiter versuchen.
Hast du dir mal alle bilder von mir auf mein HP angesehen ?
da war auch eines der Software drauf.
Wo mir noch ein bischen das verständins fehlt ist der Teil mit der Hardware
die Hängt doch auch bei dir adem controller oder nicht ?
Oder ging es da mehr um die Tür die du in deiner aus arbeitung ansprichst ?
was ich mir noch gut vorstellen könnte ist folgendes du kannst in dem prg das ausgeführt wird den Befehl eingeben Send TCP 127.0.01 DATA
dann könnte ich die daten einfach an ein adresse schicken. im gegen zu mach ich ein port auf an dem man was schicken das auch wieder die Programm verarbeitung an stösst. So wäre man Platform und soft un ab hängig un niemand kann das habt programm zu stehen bringen. Für die Remot verbindung ist so was schon implementier nur da steht die Verbidung so das der Remote pc wenn er einmal angemeldet immer daten schicken kann. (Fernsteur quasi um sonst). Um tcp nachrichten zu empfangen sollte es auch in java was geben.
So jetzt werde ich mal ein bild malen damit klar wird was ich meine
Gruß
Warum willst du auf dem roboter PC ein desktop für was ?
Johannes
10.06.2004, 18:43
Moin!
> Warum willst du auf dem roboter PC ein desktop für was ?
Nein, will ich gerade nicht! Der Grundstock sollte gerade ohne irgend eine grafische Oberfläche sein.
Ja genau, mache mal eine Skizze. Auch ich werde vielleicht nochmal etwas hier posten, um meine Vorstellung darzustellen. Dann können wir schauen, was wir von dem allen gebrauchen können und wie man es realisieren könnte.
Also mit der Hardware ist das folgendermaßen. Meine Software läuft momentan nur auf dem PC. In ihm ist ein Treiber eingebunden, der per Funk mit dem Controller kommuniziert. Auch eine elektrische Tür hätte einen Treiber. Wenn der Roboter nun durch die Tür will, schickt er per Funk eine Nachricht (also er setzt eine Variable, aber das würde ich dann lieber mit so einem Gateway lösen). Nun hat der Treiber der Tür eine Variable (Status offen oder zu). Und es gibt eine Beziehung zwischen der Variable des Roboters und der Status-Variable der Tür, sodass der Status auf offen gesetzt wird, wenn der Roboter etwas entsprechendes sendet.
Dazu muss ich aber sagen, dass zum Zeitpunkt der Präsentation das noch nicht realisiert war, sondern nur theoretisch machbar gewesen wäre. Wir sind mit dem Thema nicht ganz fertig geworden, und darunter fiel auch die Anwendung unserer Software ;-) Aber da es bei uns um den Ablauf des Systems ging, hat es für den 3. Platz gereicht.
Gruß
Johannes
Johannes
10.06.2004, 18:48
Ich war eben auf deiner Seite, aber ich habe kein entsprechendes Bild gefunden. Kannst du nochmal den genauen Link sagen?
Gruß
Johannes
P.S. Ich bin jetzt für zwei bis drei Stunden nochmal in der Schule, aber dann komme ich nochmal ins Forum. Und dann geht es hier auch von meiner Seite weiter ;-)
NumberFive
10.06.2004, 19:17
nun mal ein übersichts bild
bis auf den roten teil ist alles exitent natürlich fehlen noch gewisse internet funktionen aber es tut und läst sich aufbauen.
Was meine Aussage zu Thema Sensor angeht die Menge liegt Zur zeit nur aun den verwendeten Protokoll zur RS 232 das habe ich hatlt mal so definert.
A<sensornummer 1-254><sensorwerte1-254>E
Also genau vier Bytes lang 0 geht nicht da ich das nicht durch die COM schicht bekomme wenn ich den standart nich verlassen möchte. wenn Also
so ein telgramm von Controller kommt geht es weiter an den MessageCatcher der setzt dann die Variable SENSORXX mit dem gelieferten wert ist die variable nicht vor handen wir sie erzeugt.
Dann wird der Prg interpreter gestartet.
In meiner Idee währe es so garmöglich das Prg zu lauf zeit zu wechseln. den der MessageCatcher lädt da prg zu programm start.
das heist mann kann es in der db aus tauschen. wenn dann das neu programm haben will braucht man nur per remote sagen neuladen und schon kann es weitergehen.
NumberFive
10.06.2004, 19:22
Hallo Johannes
Natürlich geht es dann weiter du hast mein "Kampf" Geist geweckt.
Johannes
10.06.2004, 21:55
Moin Numberfive,
vielen Dank für die Zeichnung, ich werde nun versuchen, deinen Ansatz zu verstehen ;-)
Könntest du nochmal genau erklären, was der MessageCatcher für eine Aufgabe übernimmt?
Gruß
Johannes
Johannes
10.06.2004, 22:08
Zur Information: Obwohl ich mich gerade mit Numberfive per ICQ getroffen habe, haben wir entschieden, unsere Diskussion hier fortzuführen, damit andere User alles mitverfolgen können und eventuell auch ihre Ideen beisteuern können.
Zu den Programmiersprachen: Ich denke schon, dass wir die Stärken der Programmiersprachen ausnutzen sollten. Wir müssen nur klare abgenzungen machen und einen Kommunikationsweg finden, auf den von beiden Seiten zugegriffen werden kann. Ich habe von dem ganzen TCP ehrlich gesagt keine Ahnung, vielleicht könntest du mir das mal kurz erläutern.
Gruß
Johannes
NumberFive
10.06.2004, 22:08
Hallo johannes,
also der MessgeCatcher mach eingegenlich nicht so viel und doch alles
klingt komisch aber so ist es.
Er stell ein COM interface zu verfüggund das vo anderen Application genutzt werden kann. besser als dll laden den da läuft das andere im eingen process raum un kann mich nicht abschissen.
wenn jetzt ein nachricht über das TCP inface kommt oder über das COM interface versuche er sie zu interpretieren. ES gibt nachricht die intern gehändelt werde und nachrichten die als daten interprtiert werde.
wenn jetzt ein nachricht kommt die daten enhält
werde die variablen gestzt und der programm interpreter gestarten.
Der Programm Interpreter hat zur zeit zwar nicht viel funktion aber der läuft auch erst seit heute. Zu beispiel kann der jetzt be bestimmten variablen zu ständen daten wo hin schicken.
Beispiel:
SensorCatcher schickt SENSORDATA|SENSOR|63|VALUE|63
MessageCatcher Setzt jetzt die Variable SENSOR63 auf 63 und
Startet den programm interpreter wenn du dir das prg weiter oben im Thread an guckst was du was am Controler an kommt oder ?
NumberFive
10.06.2004, 22:27
zu thema tcp:
also das ist ein netzwerk protokol aber ich denke das weiß hier jeder.
wo es genaug im osi modell liegt weiß ich auch nicht mehr. jetzt gibt es funktion (meines wissenes in alle sprachen) mit den man die dies packete lesen und schreiben kann. einer ist halt server und einer Client. bei mir läft das dann so die ersten 2 bytes sind die länge des folgenden string der beliegt sein kann auser 0 byte das liegt aber an meiner porgrammierung.
Aufgrund de nachr frage von Johannes per Icq:
dll -> seid windows 2.0 programm Code der zur laufzeit in das programm geladen werden kann der code läuft im selben process raum. der programmier muß das interface für die Funktionen kennen sonst kann er sie nicht an sprechen.
COM dll oder inprog server imprinzi das selbe wie ein dll aber die interface beschreiung ist standart und die berschreibung wird in der regestry ab gelegt jeder kann sinch das interface an guken.
exe mit com interface oder out proc server stell ein interface bereit aber die soft ware läuft in ein eigenen process bereich. für das marshalling zeich windows verantort lich aber programmier fehler. schicken ein ander nicht unbedingt ab es seiden man schaft es windows zu killen.
es gibt dann noch dcom aber das würde jetzt zu weit führen.
Johannes bei TCP auf dem local rechner geht es natürlich genauso wie über netzt. Mach ich in der firma sehr oft. Ausserdem du auf Mysql zu greifst gedas so oder auf ein Oracle oder es gibt tausend fällt wo das dein windows kiste macht.
Gruß
Johannes
10.06.2004, 22:35
OK, danke für die Erklärung, ich werde mich mal über diese COM-Objekte informieren. Aber ich nehme mal an, dass es die nur unter Windows gibt.
Wäre es nicht theoretisch möglich, alle Kommunikationen der Einzelkomponenten per TCP zu regeln? Das wäre natürlich gar nicht mal so unpraktisch, da Plugins auf mehreren Rechnern verteilt sein könnten.
Wenn ich mal an meine Software denke, könnte man dann ja per Netz auf einen Server zugreifen und Sensordaten abfragen. Natürlich nur mit entsprechender Autentifizierung.
Sag mal, ginge das nicht nur mit exe-Files und TCP?
Gruß
Johannes
NumberFive
10.06.2004, 22:51
hallo johannes,
Com Dlls sind ActivX-dll nur ohne Oerfläsche nur reiner Code.
Die kennst du laut deiner Ausführungenn aus deiner HP.
Alle Componeten auf TCP Basis an zu binden fände ich
aus Geschwindigkeits gründen nicht so dolle aber ist durch aus programmierbar. Aber was spricht da gegen das produkt so zu bauen das es zwei standart Addons gibt den SensorCatcher und die Video Erkennung.
wenn dann wriklich mal die protierung auf Linux kommt kann dann immer noch mal drüber nachen denken. das zu ändern. der Sensor catcher
kann ja so erweitern das er ein etwas groß zügigeres Interface hat as das bis jetzt ist. dann pass auch wirklich jeder Controller dran. In anbetracht meiner erfahrungen hier im Forum braucht jeder so ein programm was die seriale ein liest. und das viedeo progr finden auch guten an klag. also
könnte man schon ein paket draus machen.
Achso ein add on habe ich noch mehr aber das wurde von mir nicht mehr gepfelgt da kann den RCX von Lego mit ansteuern. Aslo rund um eigendlich schon relativ komplett um ein robi mit PC zu bauen.
Wenn ich mal spinne:
Standart Board hier aus den netzt unsere Software drauf und roboter fährt.
Fast wie ein baukasten den mach fast unendlich erweitern kann. den der Avr ist frei programmierbar und der Messages catcher in gewissen grenzen auch. Man könnte bei dem konzept sogar ein Internet Client bauen.
Dann kann jede den robi per web seite steuern. dann mußt halt nur noch ein zweite cam für bild auf den robi machen.
Johannes
10.06.2004, 23:03
Ja, wunderbar. Also wie müssen aber die Sachen unbedingt logisch trennen.
Grundstruktur: Entspricht soweit ich es verstanden habe deinem MessageCenter. Es sollte die variablen verwalten etc.
Addons: Die habe ich früher Plugins und Treiber genannt, aber die kann man zusammenfasssen. Schließlich ist alles ein Programm, dass sich in das System einklinkt.
Was mir allerdings noch nicht ganz gefällt ist die Sache mit dem Sensor-Catcher und der Cam. Im Prinzip ist das alles wunderbar, und wir könnten dann natürlich auch Addons programmieren und mit zur Verfügung stellen.
Ich habe nur etwas mit der Schnittstelle Probleme. Ich habe das Gefühl, dass die Sache an dieser Stelle zu speziell wird. Wenn COM-DLLs die Ähnlichkeit mit ActiveX-Dlls haben, wie du es oben beschrieben hast, dann muss doch in dem Grundprogramm ein Verweis auf diese dort sein.
Wie soll es dann möglich sein, auf andere neue Addons zuzugreifen? Also, wie sollen dann neue Addons hinzugefügt werden. Das müsste man dann per Late Binding machen (wie ich es auch im Moment habe)...
Wenn wir ein Cam-Addon haben, sollte es meiner Meinung nach möglich sein, beispielsweise auch zwei Cams anzusteuern. Auch wenn es kaum jemand macht, wäre das prinzip ganz gut.
Wollen wir uns nicht auf eine Schnittstelle erst einmal beschränken? Und ich glaube nicht, dass die GEschwindigkeit zu gering werden würde, wir übertragen ja keine Bilder o. Ä..
So, morgen geht es weiter. Aber ich glaube, es wird ;-)
Gruß
Johannes
NumberFive
10.06.2004, 23:40
Hallo johannes,
nein ich denke nicht das Com an dieser Stell dann zu spezial wird.
den der Messages Catcher muß nicht un bedingt das Prg kenn das über die com zu greift den die daten werden wie bei tcp als String übertragen.
Aber wenn jetz jemand wirklich zwei cams drauf machen will kann er doch einfach die interne Cam Schnittstelle ab schalten. des wegen tu doch der MessageCatcher immer noch.
Bei dem SensorCatcher ist es noch Einfacher ein Prg zu lesen des Serialen port brauch nun wirklich jeder falles doch passiert das jemand nicht braucht abschalten. Das Telegramm könnte man auch so gestalten
das es freier wird. Zu beispiel so:
A30ByteE
Alles was jetzt zwischen A und E steht wird vom MessageCatcher interpretiert. Dann kann nun wirklich alles machen. dun diese telegram auf ein Microcontroller zu realieren dürfte nun kein porblem sein.
Am MessageCatcher kämmen dann halt nur die 30Bytes an.
die könnten dann so Aussehen:
SET|VARNAME|VALUE|VARNAME|....|END
dann tut der MessagesCatcher dan das un dann ruft er den Interpreter auf.
das ist dann genauso als währe er über TCP an gebunden
da sieht dann das telegram genau gleich aus.
Die 30Byte sind nur so ne zahl den ich denke so viel braucht man nicht
den rest den man nicht brauch füllt man einfach mit Leerzeichen auf.
Natürlich ist das nicht das kompacktes format aber es versteht jeder.
Eine frage währe da noch zu klären sind die TCP verbindungen immer offen oder werde sie dynamisch auf und ab gebaut ? habe beides schon programmiert tendier aber eher zu stehen verbindungen aber dann ist
bei rechnerich bei 65536 Verbindungen schluß wo bei dieser wert nur theoretisch ist denn mann kann im tcp nicht alle ports für seine eigen sachen verwenden.
Was ich schon realiesiert habe ist folgendes Ein programm Stelle ein port zu verfügung an dem man sich an melden muß. Der gibt dann ein port zu rück. Der an melden legt auf un connected sich auf den neuen port der dann ihm alleine gehört. Da hat zur folgen mann hat bei konfigurieren nicht so viel arbeit das mach die Software selbst.
Gruß
Johannes
11.06.2004, 07:34
Moin Numberive,
habe deine Mail bekommen und werde sie und dein Post nochmal genau durchlesen. Aber ich glaube, dass ich mit mit diesem COM-Kram einen zu großen Kopf gemacht habe, denn was du in der Mail beschrieben hast ist eigentlich genau das, was auch ich gemacht habe. Ich werde das ganze mal überdenken.
Noch etwas zur Plattformunabhängigkeit: Auch wenn es nicht gleich Linux ist, wäre es doch auch ganz schön, wenn die Sache auf einem PDA (Windows CE) laufen würde. Weil der ist schön klein, leicht, man hat keine Probleme mit der Stromversorgung, etc. Aber ich weiß nicht, wie man solche PDAs programmiert, außer mit AppForge MobileVB. Das ist ne spezielle Umgebung. Ich würde es ziemlich gut finden, wenn man auch eine PDA-Version ohne großen Aufwand kompillieren könnte.
So, muss zur Schule.
Gruß
Johannes
Johannes
11.06.2004, 12:21
Moin Numberfive,
ich werde mich jetzt mal ausführlich über schnittstellen aller Art informieren und schauen, wie wir am besten unsere Codes zusammenbekommen und Addons realisiert werden könnten. Ich werde dann nochmal posten.
Ich bin sowieso der Meinund, dass wir erst einmal Testcodes schreiben sollten und diese besprechen. Wenn wir dann später ein paar Erfahrungen gesammelt und ausgetauscht haben, können wir mit der eigentlichen Programmierung anfangen.
Gruß
Johannes
NumberFive
11.06.2004, 15:31
Hallo Johannes,
linux auf ein PC währe sicher noch machbar aber das auf ein PDA zu potieren sehe ich schwarz den da wird nie ne datenbank laufen.
Ich denke an diesem Punkt der größe können wird uns auf die
Hardware industry verlassen die werde schon kleiner und nicht so batterie
tötent. Was das System aber zu lassen würde währe man pack ein PDA auf den Robi und dann lässt man den per WLAN die Daten des robi schiken und wieder zurück. Das würde gehen Läuft der SensorCatcher auf dem PDA und der Rest irgendwo anders.
Aber vielleicht sollten wir uns erstmal auf ein Windows version ein schisse
die bauen und wenn sie fertig ist das potieren angehen. Zu hohe anforderungen führen irgend wann zum furst weil man nix hin bekommt.
Rede aus erfahrung
Gruß
Johannes
11.06.2004, 15:36
Moin,
deshalb denke ich in JAVA ;-) Das System, das mir vorschwebt, ist aus mehreren Modulen aufgebaut. Und die PDA-Version muss ja keine Datenbank unterstützen. Da wäre es ja möglich, dass der PDA per WLAN mit einem PC, auf dem ebenfalls die Software läuft, jedoch mit mehreren Modulen ausgestattet ist, kommuniziert. Das sollte kein großes Problem sein.
Ich bin gerade dabei, eine Grafik zu entwerfen, auf der ich mal alles darstellen werde.
Gruß
Johannes
Johannes
11.06.2004, 15:38
P.S. Die Umstellung einer fertigen Software auf ein neues System ist nicht so ganz einfach. Besonders wenn man an das ganze ActiveX denkt und damit die Kommunikation aufbaut, wird eine Umstellung fast unmöglich. Deshalb sollte man gleich an solche Dinge denken.
Wie ich das sehe kommt ihr was die Portierbarkeit angeht wohl nicht um Java drumrum. .NET wäre ne Alternative aber kein großer Unterschied.
Problem dürfte halt die Einarbeitung sein sein, da beide Systeme mit großen und ziemlich verschachtelten Objekten arbeiten, in die man sich halt erst richtig einarbeiten muss. Da kosten schon Kleinigkeiten ne Menge zeit bis man rausgekriegt hat, wo welche Methode in welchen Objekt sich für was eignet.
Habt ihr euch mal das Ding bei SourceForge angeschaut. Da gibt es doch auch ein Roboter-Projekt (ich glaub "Open Automation Project"). Haben die da nicht auch schon Software geschrieben, die man weiterverwenden könnte ?
Ich würde mich da ja gerne mit dran hängen, aber die ganze Sache wäre mir zu teuer. (kleines Board 200 EUR, passendes Netzteil 70 EUR).... und die ganze Mechanik, Motoren ,... .
Johannes
11.06.2004, 16:38
Moin,
bei .net bliebe man dann ja auch bei Microsoft und ich möchte eigentlich zu Linux umsteigen, was meine Roboter-Projekte angeht. Man sollte auch nicht übersehen, dass JAVA auch noch andere Vorteile gegenüber anderen Sprachne hat. Da gibt es im Internet genug drüber, nur, damit wir nicht vom Thema abkommen und darüber diskutieren ;-)
So, ich habe jetzt mal ein paar Grafiken gemacht. So stelle ich mir im groben eine Steuersoftware vor. Da ich ja bereits eine sehr gut funktionierende Software für Windows habe, möchte ich nun doch plattformunabhängig (auch wenn dafür mehrmals kompilliert werden muss) und noch modularer werden.
http://www.mindrobots.lernnetz.de/projekte/srcs/schema1.gif
Hier ein Beispiel (Roboter oben, PC unten. Beide haben die main control installiert, die plattformunabhängig ist.):
http://www.mindrobots.lernnetz.de/projekte/srcs/schema2.gif
Und nun zu der Programmierung:
http://www.mindrobots.lernnetz.de/projekte/srcs/schema3.gif
Gruß
Johannes
Johannes
11.06.2004, 16:53
Moin matren,
du meinst, mit an unser Projekt dranhängen?
Also, meiner Vorstellung nach müsste auf dem Roboter selber gar kein PC installiert sein. Die Software kannst du auch nur auf dem PC verwenden. Sie könnte über ein Addon ein Funkmodul ansteuern, das mit deinem Mikrocontroller kommuniziert. Da könntest du dann immernoch viele Features nutzen.
Gruß
Johannes
Na gut, wenns denn so angedacht ist, würde ich schon mitmachen.
Ich würde mich dann aber eher auf Linux und Java konzentrieren, da ich da momentan so gut wie keine Ahnung hab, da ich da bisher keine Verwendung hatte. (Ich brauch immer ein Ziel wenn ich mich irgendwo einarbeiten muss).
Momentan programmiere ich eigentlich nur mit PHP (früher mit Perl), da ich hauptsächlich Business-Anwendungen fürs Intranet schreibe (und ohne Datenbanken läuft da natürlich nichts: Oracle, MSSQL, MySQL). Zu früheren Zeiten habe ich hauptsächlich in VB programmiert, ist aber schon ne weile her.
Im Elektronik-Bereich bin ich ja eigentlich ein Anfänger, hab mein RNBFRA erst kürzlich gekauft. Aber das wird auch noch.
Also wenn Ihr etwas Unterstützung braucht, dann bin ich dabei.
Johannes
12.06.2004, 02:35
> (Ich brauch immer ein Ziel wenn ich mich irgendwo einarbeiten muss).
Genauso geht es mir, vielleicht können wir uns da gegenseitig helfen. ;-)
Aber auch allgemeine Mitarbeit bei der Planung würde helfen.
Gruß
Johannes
P.S. Dann gehe ich nun mal ins Bett (bin gerade von ner Fete wiedergekommen) und hoffe, dass ich morgen ein paar Kommentare zu meinem Ablaufplan von euch lesen werde.
Wenn ich da richtig verstanden habe wills Du eigentlich ne Art Bussystem benutzen (oder sagen wir Protokoll) das auf ein oder mehrere bestehende Kommunikationsprotokolle (z.B. TCP) aufsetzt über den alle Komponenten kommunizieren können. So ganz klar ist mir das aber noch nicht.
Ich muss jetzt leider ins Büro, bin erst heute Abend wieder da, dann können wir das ja diskutieren.
Gruß
NumberFive
12.06.2004, 10:56
Hallo marten,
erst einmal will kommen im boot. schön das noch jemand mit programmieren möchte. Kenne ein firma in Frankfurt die zur zeit alte rechner verkauf für unter 100 Euro natürlich nix dolles aber. um die Maincontrol laufen zulassen
öhen viedeo sollte es wohl reichen. Aus deine Aussagen erkenn ich das für dich sql kein Thema ist. Schön. Werde jetzt die Angaben von Johannes mal
in mein Überlegungen einarbeiten un das ergebnis dann hier Posten.
Samstags Büro ?
PS: habe mir frei genommen von der freunden damit wir hier was schaffen können. Ich hoffe es lohnt sich
Johannes
12.06.2004, 13:06
Moin,
das erste, was wir brauchen, ist ein Schema, dass keine Wünsche übrig lässt.
Ja, matren, das Grundlegende ist ein Bussystem und ich tendiere da zu TCP, da es von vielen Programmiersprachen verstanden wird und dann auch übers Netz Komponenten kommunizieren können, sogar mit unterschiedlichen Betriebsystemen.
Jede Komponente ist dann somit ein eigenständiges Programm, was auch sehr sicher ist und das System praktisch nicht durch eine Komponente aufgehängt werden kann.
Ich kann ja nochmal etwas meine Zeichnungen erläutern.
Aufbau der Software
Das grundlegende Element der Software ist die main control. Obwohl sie relativ simpel aufgebaut sein kann, hat sie grundlegende Aufgaben und muss schnell sein. Wichtig ist hier die Plattformunabhängigkeit, da dieses Modul auf allen Robotern oder Kontrollrechnern istalliert ist. Also, wir wiollen einen Roboter und einen Kontrollrechner vernetzen, dann muss auf beiden Geräten die main control installiert sein. (dazu weiter unten noch mehr)
Über den Gateway werden Informationen ausgetauscht. Deshalb sollte auch der Gateway plattformunabhängig sein.
So, dann kommen die Addons, und in ihnen unterscheidet sich der Roboter von dem Kontrollrechner. Addons können alle Aufgaben übernehmen.
Möglichkeiten
Der Roboter wird seine Motoren und Sensoren wahrscheinlich über einen Microcontroller ansteuern. Deshalb muss die Software mit einem Addon versehen werden, über das sie mit dem Controller kommunizieren kann. Schließlich kann der Controller mit großer Wahrscheinlichkeit nicht TCP, weshalb das Addon zwischen TCP und z.B. Serieller vermitteln muss. Dieses Interface hängt vom Controller ab, und natürlich muss auch auf dem Controller etwas programmiert sein, dass mit dem Addon kommuniziert. Wahrscheinlich muss hier jeder Anwender für seinen Anwendungszweck etwas programmieren, aber man könnte Beispielcode liefern. Das hängt natürlich etwas davon ab, wie bekannt und verbreitet unsere Software wird.
Jetzt muss aber irgendwo noch das Verhalten des Roboters geregelt werden. Das macht man ja normalerweise auf dem Controller. Wenn man allerdings einen Rechner auf dem Roboter hat, kann man das verhalten natürlich mit einer höheren Programmiersprache programmieren. Das ist ja dass, was Numberfive und ich vorhaben, unabhängig von diesem Projekt.
Die Verhaltenssteuerung kommuniziert auch per TCP mit dem Rest der Software und kommt so an Sensorwerte, kann Motoren ansteuern und auf andere Addons zugreifen. Zum Beispiel auf ein Kamera-Addon. Das schöne hieran ist natürlich, dass man das Verhalten ändern kann, ohne an den anderen Modulen rumfummeln zu müssen.
So, jetzt kommt etwas, was nicht unbedingt so sein muss, wie es in meiner Grafik ist. Nämlich das Kommunikations-Addon. Theoretisch könnte man, um eine WLan-Verbindung herzustellen, direkt an den Gateway rangehen, da Wland ja auch über TCP läuft. Das würde heißen, dass es nicht zwei Gateywas, also der vom Roboter und der vom Kontrollrechner, sondern nur einen gibt, den sich beide teilen und der teilweise über Funk läuft. Das gefällt mir eigentlich noch besser.
Aber dazu muss ich sagen, dass ich mich mit Netzwerkprogrammierung NOCH nicht gut auskenne und deshalb nicht weiß, wie gut das zu realisieren ist.
Die Kontrollsoftware hat natürlich andere Addons. Zum Beispiel eine GUI, mit der der User den Roboter steuern kann, also Befehle senden kann, etc.
Soweit zum Aufbau, jetzt kommt was zur main control.
Hier habe ich viele Ideen, schließlich ist es das Herz des ganzen Systems.
Wir haben ja den Gateway, durch den Nachrichten geschickt werden können. Hier müssen wir uns also ein System überlegen, über den zum Beispiel die Verhaltenssteuerung an die Daten des Kamera-Addons kommt. Hier würde ich vorschlagen, dass es ein onDemand-Prinzip wird. Die Verhaltenssteuerung sendet eine Anfrage, die Daten kommen zurück. Auch hier kann es natürlich Abwandlungen geben, zum Beispiel, dass es das Kameramodul der VErhaltenssteuerung oder einem anderen Addon im System ermöglichst, sich anzumelden, sodass automatisch die Daten zugeschickt werden. Wenn also alle 10 Sekunden etwas von der Kamera zur Verhaltenssteuerung (VS) übertragen werden soll, könnte sich die VS in einer Verteilerliste der Kamera eintragen. Damit würde man sich das Demand sparen und den Bis entlasten.
Was aber noch wichtiger ist, ist das Veröffnetlichen von Daten, und das übernimmt die main control. HIer können Variablen definiert werden, in die von überall etwas eingetragen werden kann. Ich werde, wenn wir das System irgendwann mal fertig haben, ein Addon programmieren, mit dem der Roboter Hinternisse in eine Karte einzeichnen kann und den Weg dadruch berechnen kann (das habe ich ja im Rahmen meiner Jufo-Arbeit schon programmiert).
Jetzt wäre es aber sehr praktisch, wenn die Karte global verwaltet wird, und auch andere Roboter etwas in die Karte einspeichern könnten. Somit könnten mehrere Roboter organisiert werden und zusammen ein Gebiet erkunden. Dafür ist es wichtig, dass sich alle Main-controls untereinander abgleichen. Wenn man also auf dem PC die Karte editiert, muss sie automatisch auf allen Robotern aktualisiert werden.
Auch wenn das schon relativ kompliziert ist, könnte unsere Software für sowas einen großen Beitrag leisten.
Soweit zu meinen Ideen, und sorry, dass es wieder so viel Text geworden ist ;-)
Gruß
Johannes
NumberFive
12.06.2004, 13:15
Hallo,
der eintrag wurde offline verfasst also nicht wunder wenn es nicht 100% passt.
nun mein gedanken zu Thema. Leider muß ich eines Feststellen:
Ich habe kein Probelm damit wenn teile der Software in Java laufen wenn tun ist egal wo mit. Aber ich kann java im Moment nicht auch noch lernen kann Delphi und c++ ein bisschen Html und PL/ Sql unter Oracle. Im Moment habe ich zwei große Projekte am laufen aus diesem hier das packe ich zeitlich wirklich nicht. Noch dazu wo ich jetzt noch Bascom lernen muß für meinen AVR.
Bitte habt verständniss.
Aus diesem grund würde ich folgendes Vorschlagen:
Ziele Version 1:
MessageCatcher schreiben wir in C++ (VC 6.0) Windows platform
SensorCatcher C++ Windows Serial Input für MircoControler an bindung über COM
RoboCam C++ DirektX anbindung über COM
Karten erstellung in java anbindung über TCP
Konfiguration tool in ? Php ?
RemoteControl in ? Anbindung über TCP
MessageTransfer für den PDA in Java
Alle Konfig daten werde in INI Files abgelegt
MessageCatcher hat zu griff auf einem MySql Server für die Daten
Bitte nicht auf schreien werde es versuchen zu erklären.
Der Hauptgrund für mein Vorschlag ist der das bei dieser Lösung schon reativ viel Fertig ist und läuft und sich in meiner Arbeit große synergie effeckte erreichen lassen. Ich weiß ja nicht welche Projekte bei euch so anstehen deshalb kann ich das nicht ein schätzen und mache diesen Vorschlag. Bitte nich als gegen annehmen sondern als diskustion Grundlage.
Im MessageCatcher wird die COM Schnittstelle so weit wie möglich isoliert
damit sie für ander Betriebssystem entfernt werden kann. Der MessageCatcher ist auch
ohne die zwei standart Addon voll funktionsfähig.
Für mein nachfolgenden ausführungen gehe ich von folgende gebenheiten aus:
Es gibt zwei PC's den PC an dem ein Mensch Sitzen kann (RemotePC) und den RobiServer der entweder im robi ist oder für die wo es zu groß (teuer) wird
ist er über TCP über WLAN oder Funk RS 232 mit dem robi verbunden.
Siehe dazu Bild 1
Also bis auf das Addon interface gibt es das ganz schon zwar nicht voll ausprogrammiert
aber ich könnte das Zeigen. Allerdings nur hier oder müsste jede menge rechner rum tragen.
Zum Ablauf:
Das RemoteInterface halt alle Recht und mehr befehle absetzten als der rest.
Die GobalControl immer alles Entgegen und Interpretier das ein kommen
Telegramm. Wenn das Telegram es vordert werde Variablen gestetzt
und der ProgrammInterpreter gestartet oder Die funktion im MessageCatcher
ausgeführt. Die Telegramme sehen immer so Aus TEXT|TEXT|TEXT...
es durfen keine 0 Bytes enthalten sein. Bei der Übertragung über
tcp wird nur noch die länge des Textes vorne angestellt. Damit die gegenseite weiß wann das telegramm voll ständig war (bei TCP kann zu verstückeling der telgramme kommen)
aber darum das kümmert sich das Addon interface oder das RemoteInterface.
Jedes Addon hat einen Eindeutingen Name über den es dann an gesprochen werden kann. Im Prinzig kann jedes Telegramm von Überall kommen oder Hin geschickt werde
ohne das eine zeile sourcecode geändert werden muß.
Bsp:
SensorCatcher Sendet :
MESSAGECATCHER|RUN|SET|ADDON|1|SET|DATA|DASISTEINT EST
Der MessageCatcher setz die Variablen:
ADDON = 1
DATA = DASISTEINTEST
Da nach wird der wird der programmInterpreter gestartet irgend wo in Script
steht:
IF ADDON = 1 THEN
Send ADDON VAR DATA
END IF
jetzt passiert folgendes der MessageCatcher bekomme den auftrag
an das device/addon mit dem ADDON den inhalt der Variable DATA
zu senden.
Ich denke viel freier kann es nicht gestallten wenn man es realiesierbar halten möchte.
In dieser Form hat der MessageCatcher nichts mit dem ablauf im roboter zu tun
sonder das verhalten wir allein über den script bestimmt. Und die leistungs fähigkeit
wird allein die Fähigkeiten des Interpretieres bestimmt un ist aus baubar.
Wenn man es über treib hääte man sogar ein eingene script sprache.
Es wird in ein Zyklus ein Tegramm an alle componet geschikt
damit man weiß das sie noch leben. Wenn da kein antwort mehr kommt
werden sie ab gemeldet. Was im in meinem Robi nach her machen werde
ist das bekommt der AVR kein lebenszeichen mehr restet er den ganzen PC
Hardware mässig. So sollte eine Dauer betrieb möglich seid so lange
es noch strom gibt.
So jetzt habe ich alle meine geheimnisse Preis gegeben nun macht was draus.
Gruß
NumberFive
12.06.2004, 13:16
So johannes
meiner ist auch nicht viel kürzer *g*
Gruß
Johannes
12.06.2004, 13:16
Nochmal was zu PDAs:
Man müsste auf dem PDA ja nur die main control und zum Beispiel eine Verhaltenssteuerung installieren. Kompliziertere Dinge wie Datenbanken oder Kameraverarbeitung sind natürlich nur auf rechenstärkeren Computern möglich.
Und zu normalen Controllern ohne Rechner auf dem Roboter (betrifft dich, matren):
Es ist natürlich auch möglich, die Software nur auf dem PC zu installieren und ein Addon zu programmieren, dass mit dem Controller kommunizieren kann. Da gibt es ja viele möglichkeiten fernab von WLan etc. Dann kann man immernoch die GUI nutzen, Daten anzeigen und ändern.
Gruß
Johannes
Johannes
12.06.2004, 13:26
So, hatte bei meinem Post deinen noch nicht gesehen.
Mein Standpunkt ist folgender, du musst JAVA ja nicht lernen, du schreibst die C++ Routinen und ich den Rest, vielleicht findet sich ja noch jemand außer matren. Nur ich möchte nun eine komplett durchdachte und zukunftssichere (im Sinne von Erweiterungsmöglichkeit und Portierbarkeit) Software programmieren. Du sagst zwar, dass du vieles schon fertig hast, aber ich habe schon eine lauffähige Software, die fast alles das kann, was ich oben beschrieben habe.
Allerdings läuft sie mit ActiveX-Komponenten, ist mit Visual Basic programmiert und damit auf Windows fixiert und kann noch nicht die Sachen, die mit einer plattformunabhängigen main control und einem universellen Gateway möglich wären. Und gerade so etwas möchte ich in Angriff nehmen.
Deshalb habe ich mir gedacht, dass wir im Moment noch gar nicht groß programmieren sondern ein Schema entwickeln, Lösungsansätze suchen, dann noch ein paar Leute zusammensuchen und dann programmieren, gleich dabei Fehler ausmerzen und die Funktionalität optimieren. Ich selber finde auch nicht, dass die Software möglichst schnell fertig sein muss, sondern möchte eher einen Greundstock entwickeln, auf den möglichst viele Leute verwenden und ihre Module dafür schreiben.
Gruß
Johannes
NumberFive
12.06.2004, 13:28
Hallo Johannes,
in deinem Posting ist nach meine denken ein großer denk fehler drin.
mehr als eine Maincontrol und du kommst in arge verwaltungsprobemle
(Clustering) der Overhead hier führ ist für die Version 1 zu hoch.
Aber ich könnte mir folgendes vorstellen das man ein Addon schreibt
das das zwei Roboter verbindet damit eine Team arbeit möglich wird
finde ne klasse idee dann könnten wir fussball spielen wenn wir uns treffen
*g*. Als daten basis für die karten könnte man doch den Mysql nehmen so könnten alle Addon was da mit machen.
Nochmal ich halte nicht aber auch garnichts von irgen welchen pollen programm abläufen soweit es irgend wie geht immer auf events gehen.
Leid volle erfahrung.
Gruß
Johannes
12.06.2004, 13:31
>in deinem Posting ist nach meine denken ein großer denk fehler drin.
Nein, überhaupt nicht. Die Maincontrols werden benachrichtigt, wenn sich irgendwo ein Wert ändert. Das ist gar kein Problem.
Wo ist denn ein Problem beim pollen? Wenn ein Modul Daten haben will, sendet es eine Anfrage und wartet, bis die Daten zurückkommen.
Gruß
Johannes
Johannes
12.06.2004, 13:52
Moin Numberfive,
ich habe nun dein Post durchgelesen. Was ich nicht ganz verstanden habe ist, folgendes. Jede Message geht zum MessageCatcher? Ich würde es sinnvoller finden, wenn über die Adressierung der Message direkt das entsprechende Addon anspringt. Wir haben zwei verschiedene Ansätze.
Du trennst direkt zwischen Steuerpc und Roboter. Ich bezweifle, dass dies besonders effizient ist. Da ich eigentlich immer in größeren Dimensionen denke, sehe ich dort eine große Einschränkung. Du schreibst, dass man ein Addon schreiben könnte, dass zwei Roboter verbindet. Hingegen gehört bei dir der MessageCatcher direkt zum System.
Bei mir ist es genau anders herum. Die Aufgabe der Software sollte sein, einen Bus zur Verfügung zustellen, über den mehrere Komponenten, nicht nur Roboter, vernetzt werden können. Wie dann die einzelnen Komponenten ihre Messages verarbeiten, ist ihnen überlassen.
Zu der Sache mit den mehreren main controls. Ich bin gegen eine zentrale main control, da dann die Roboter nicht mehr autonom und unabhängig sind. Viemehr sollte jeder Roboter eine Kopie der Daten mit sich führen, damit er sie auch benutzen kann, wenn er gerade keinen Kontakt zu anderen Einheiten hat. Ist der Kontakt hingegen vorhanden, werden die Daten immer abgeglichen.
Gruß
Johannes
NumberFive
12.06.2004, 13:57
Ok johannes,
an diesem punkt sind leider unsere Ziel nicht so ganz vereinbar das soll nicht heissen das ich aussteige. Aber das die ziel unterschiedlich gelagert sind.
Mein Ziel ist der 2.10. 2004 einen Roboter zu haben der Tut. Mit der Software bzw. mit einem Teil davon.
Doch zu rück zum Thema:
Warum immer MainControl und Gateway
den brauchst du nicht auch wenn du es portierbar halten möchtest.
was ich zu einem teil auch verstehen kann. Bin ja nicht un ein sichtig
es gibt halt nur ziele die Man hat.
Die Main control stellt einfach für alles was von aussen kommt ein tcp interface auf einem oder meheren ports zu verfügung.
Bei mir gibt es zwei ports einer für die RemoteControl und einer für die Addon's. Ähnlich wie ein http server oder der Server von icq zu beispiel.
Was hälst du von der sachen mit dem script interpreter in der Main Control da zu hast du noch nix gesagt.
Was ich mir bei tippen so überlegt habe ist:
Weil ich werde eh dran weiterschreib egal wie das jetzt hier aus geht.
Ich stelle drin und jedem der mit entwicklen möchte meine MainControl
(MessageCatcher) zu verfügung. Dann kann immer mal wieder was probieren und muß nicht nur in teorie schwälgen den das geht schief ist zu mindestens mein erfahrung.
Aber genau an die diesem Punkt unterscheiden wir uns sehr du bis mehr der theoretiker und ich programmiere lieber dann weiß ich ob etwas geht oder nicht. Und mal ganz ehrlich ich sage lieber das geht zur zeit nicht als
zu sagen das geht aber in 10 jahren immer noch nicht geliefert.
Da MessageControl und der prgrunner eigene Klassen sind sollte
es möglich sein sie auch auf ander betreibssysteme zu portieren
sofern es da für c++ sprache gibt.
Das zweit probelm was ich sehe ist der faktor zeit ander entwicklen auch und sind weiter wie wir aber warscheilich auch nicht so offen. Was das Thema schnitstelle für erweiterungen an geht.
Gruß
NumberFive
12.06.2004, 14:06
Hallo johannes,
was du beschreibst ist kein pollen. Sonder in deine posting
hast du was von zyklischen nach fragen geschrieben das ist polling und
erzeugt CPU last ohne sinn.
Zwei Maincontrols du hast bei mehr als ein das problem das ein varialbe
gesetzt wird dan nach wierd aber die Variable nicht in dem anderen gesetzt
den bist du die daten drüben hast könnte ein sensor schon wieder neue daten geschrieben haben. das heist entweder muß du wenn die eine maincontrol was empfängt die ander blokieren oder läufst gefahr
das sich befehle gegen einander auf heben bzw. varialbeln zwei
werte haben. Als ich kenn clustering vonder firma her das beisen sich leute wie oracle oder ms die zähen aus dann willst du das mal eben so programmierne sorry aber das glaube ich nicht. (nicht persönlich nehmen bitte). Es wird schon schwer genung werde die maincontrol und der microkontoller unter einen hut zu bekommen.
Gruß
Johannes
12.06.2004, 14:23
Moin,
auch schon in meinem ersten Post habe ich geschrieben, dass wir eventuell nicht zusammenkommen können, da die Ansätze doch unterschiedlich sind.
Wie gesagt, ich habe selbst vor, so eine Software zu schreiben, am liebsten natürlich als Gemeinschaftsprojekt, aber ich werde doch erst einmal den Grundstock programmieren und dann für Addons und Optimierung andere Leute mit ins Boot holen.
Bei mir ist es so, dass ich, bevor ich etwas mache gut überlege und schon an den nächsten Schritt denke, damit ich danach keine Probleme habe, weiterzumachen. Da ich meine erste Version dieser Software vor einem Jahr fertig gestellt habe, möchte ich wie gesagt nun das ganze neu und besser aufziehen. Ich verstehe aber, dass du deine Ansätze nicht verwerfen möchtest und wir dann im Endeffekt doch einzeln arbeiten.
Aber ich denke, dass wir uns so schon gegenseitig Anregungen gegeben haben. Wir können uns ja zu einem späteren Zeitpunkt nocheinmal über unsere bis dahin geschafften Ergebnissen austauschen.
Gruß
Johannes
Johannes
12.06.2004, 14:30
>Sonder in deine posting hast du was von zyklischen nach fragen geschrieben das ist polling und erzeugt CPU last ohne sinn.
Ich habe gerade geschrieben, dass zyklisches Nachfragen eben nicht unbedingt nötig ist. Stattdessen könnte man einen Verteiler einrichten, der Daten direkt an die Interessenten, die in der Liste stehen, schickt, sodass diese nicht immer danach fragen müssen.
>wei Maincontrols du hast bei mehr als ein das problem das ein varialbe
gesetzt wird dan nach wierd aber die Variable nicht in dem anderen gesetzt
den bist du die daten drüben hast könnte ein sensor schon wieder neue daten geschrieben haben. das heist entweder muß du wenn die eine maincontrol was empfängt die ander blokieren oder läufst gefahr
das sich befehle gegen einander auf heben bzw. varialbeln zwei
werte haben.
Nein nein, Sensorwerte sollten sowieso nicht von der main control überwacht werden. Es geht hier beispielsweise um Dinge wie eine Karte.
Die Übertragenden Daten müssten mit einem Zeitcode versehen werden, damit man weiß, welche Daten die aktuelleren sind. Das ist nun wirklich kein Problem.
Gruß
Johannes
NumberFive
12.06.2004, 14:40
Hallo Johannes,
Mist ich kann es nicht rüber bringen. so unterschiedlich sind die ansätze garnicht. ich hoffe ich bin diesmal schneller als du so läuft die Diskustion
zu weit auseinander. Natürlich hat jeder roboter sein eigenden
MessageCatcher. war nicht anders gemeint dann gibt es ein addon was mit anderen robtern komunizieren kann. ich meinte nur das mehr als ein main control in ein robi keine sind macht.
Nein auch ich trenne nicht zwischen RobiPC und Roboter auch bei mir soll das ein einheit werden. nur matren wollte ein kleinen roboter bauen.
So könnte man auch diesen Fall abdenken. Dann währe der roboter das stimmt nich ganz so frei halt nur so weit wie der funk reicht egal ob WLAN oder RS 232 über funkt. wenn der pc drauf ist ist er dann föllig um abhägig
deine und mein Ideen.
versuche jetzt noch mal deine Idee zu verstehen aber irgend wie sehen so wie es jetzt verstehe keine sind mehr bzw es ist zu einfach gedacht.
1. wenn du die Telegramm nicht interpertieren willst kannst du sie nicht ver teilen den irgend wo muß du ja her wissen wo sie hin müssen.
2. wenn du alle eingehen telegramme an alle im system weiter verteils
mach die software in meine augen keine sind mehr den das gibt es fertig zu kaufen bzw. nim udp kleiner bruder von tcp der schick analle die zu hören im nezt das telegramm.
3. wenn es eine art bus adapter währe müsstes du ganz viele schnistellen
implemenieren sprich so wie du es schon realiesiert hast dein treiber
und nach oben die software die interliegentz zu verfügung stellt.
das würde aber heissen das nimmand mit der soft ware allein was an fangen kann. den sie kann keier logig verarbeiten.
das heis jeder de die soft war ein setzt muß er mal ein addon schreiben in dem seine programm logic liegt und ein addon was mit dem mircocontrole komuniziert. es sein den er nimmt das was wir standart mäsig mch für der seriale schitstelle.
So jetzt noch mal zu meine Idee:
Du kannst dein programm logic in der Main control per script hinterlegen
und wenn du dann noch das standart serial interface benutzt. währe das gesamt system als solche lauffähig. Wenn jetzt dinge kommen
die für den script inter preter su komplex sind baust dir ein addon un machst du auch eine art von daten verarbeitung in dem du neu sensoren abfragst oder die bilder der cam interpretierst. und so weiter.
Das system währe föllig frei aber auch alleine lauffähig.
minimal bestrieb ein Addon für die komunikation zwischen MassageCatcher
und Microcontroller.
Ein forteil meiner Iddee ist auch du kannst dein script im konfig tool scheiben. und muß nicht irgend welche kennisse vone ien programmier sprache haben. das betriebs system brauchst du nicht zu kennen und so
weiter.
Mal sehen was du da zu meinst
NumberFive
12.06.2004, 14:56
Hallo johannes,
ein nach trag muß ich jetzt doch noch machen es läst mir kein ruhe.
warum ziehst du dich zurück ? ich hätte dich anders ein geschätzt.
Oder interpretiere ich dein letztes posting falsch
ich sag vorneweg ich hab nicht den ganzen Thread gelesen schreibe nur auf Wunsch von Numberfive.
also meine Gedanken zu dem Thema (falls es überhaupt jemand interessiert ;) :
An meinem Bot will ich logischerweise so wenig wie möglich einsetzen, denn PC o.ä. ist nur unnützes Gewicht und größe.:
Kommunikation
Bot Hardware (uC) zu und von PC
Umsetzungsideen (nur Funkideen)
RS232:
+einfach zwischen uC und PC zu bringen
-nicht wirklich schnell z.t. teuer
kein VIDEO
WLAN:
+leicht erweiterbar (insbesondere die Reichweite des LANS)
-es gibt zwar chips die man an einen uC anschließen kann, aber die sind realtiv teuer und schwer zu handeln.
=>Alternative: PDA, das schränkt sehr starkt ein (win oder Palm?) auch weitere Software wäre fällig, und keiner kennt sich damit wirklich aus oder?) schwer VIDEO zu übertragen.
Protokoll usw
Meiner Meinung nach sollte der uC einfach nur alle Daten permanent übertragen, denn wenn der uC erst die Daten rausschickt die ein PC anfordert, müssen uC und PC mehr "denken". auserdem hat man so immer die aktuellesten Werte. Und wieso Daten nicht so oft senden? Bei RS232 und vorallem WLAN lässt sich mit einem entsprechenden Protokoll alles nötige so leicht übertragen.
Ich würde aber die Daten bzw das was der Robi machen soll (ausweichen usw.) bei RS232 über extra uC machen, denn sonst kann es doch noch zu Perforamnce Problemen kommen => 2uCs einer Eingabe einer Ausgabe.
Für eine Video Übertragung wäre eine extra Leitung über Funkmodule sinnvoll, die an einen PC mit TV Karte angeschlossen sind, denn sonst gibt es je nach Reichweite die geplant wird immer Probleme. (hab mit wlan schon einge erfahrung)
Der PC
sollte die Daten die er kriegt erstmal stur archivieren (ihr habt recht mit sql oder ähnliches).
Ich bin auch für eine möglichst module Konstruktion der ganzen Software (Bsp.: nicht jeder braucht VIDEO)
zur weitern Auswertung der archivierten Daten schreibe ich nichts, denn da habt ihr schon alles wichtige erwähnt.
Fazit: Palm oder andere PDAs würde ich erstmal weglassen, denn meiner Meinung nach nützen sie bei dieser Varaiante nicht mehr viel, außer man will abnehmen und dem Robi hinterherlaufen um "Stopp anzutippen", und auch wenn ich kein Software Spezi bin, glaube ich eine so aufwändigte Soft die es werden soll, bereitet dem PDA probs. (habt ihr auch schon gepostet)
Johannes
12.06.2004, 15:49
Moin Numberfive,
ja, wir missverstehen uns ein wenig.
Weil ich werde eh dran weiterschreib egal wie das jetzt hier aus geht.
Ich hatte das so verstanden, aber vielleicht schätze ich dich falsch ein, dass du nur Mitarbeiter für dein Projekt suchst, und an deinem Code festhalten möchtest. Kann ich natürlich verstehen. Aber auch ich denke schon sehr lange über eine neue Version meiner Software nach, ich habe mir das alles oben nicht gestern ausgedacht.
Ich habe natürlich weiter Interesse an einer Zusammenarbeit und es sollte nicht wie ein Rückzug klingen.
So, jetzt zum thema.
ich meinte nur das mehr als ein main control in ein robi keine sind macht.
Ne, das stimmt. Das will ich aber auch nicht. Was ich meinte ist, dass jeder Roboter eine eigene main control hat. und die main controls des Gesamtsystems (also von Robotern, Kontrollrechnern etc) sprechen sich ab, also tauschen ihre Daten aus, damit sie auf dem gleichen Stand sind.
Nein auch ich trenne nicht zwischen RobiPC und Roboter auch bei mir soll das ein einheit werden. nur matren wollte ein kleinen roboter bauen.
So könnte man auch diesen Fall abdenken. Dann währe der roboter das stimmt nich ganz so frei halt nur so weit wie der funk reicht egal ob WLAN oder RS 232 über funkt. wenn der pc drauf ist ist er dann föllig um abhägig
deine und mein Ideen.
Ok, da haben wir uns missverstanden. alles klar.
1. wenn du die Telegramm nicht interpertieren willst kannst du sie nicht ver teilen den irgend wo muß du ja her wissen wo sie hin müssen.
Hm ich weiß nicht, was du meinst. Aber das liegt vielleicht auch daran, dass ich nicht genau weiß, wie die Datenübertragung mit TCP genau funktioniert. Vielleicht könntest du das nochmal erzählen. Darauf aufbauend kann ich dann vielleicht sagen, wie ich das hier meine.
2. wenn du alle eingehen telegramme an alle im system weiter verteils
mach die software in meine augen keine sind mehr den das gibt es fertig zu kaufen bzw. nim udp kleiner bruder von tcp der schick analle die zu hören im nezt das telegramm.
Doch, mit Software (also der main control) können Daten als public verwaltet werden, sodass mehrere Roboter auf die gleichen Daten zugreifen können.
das würde aber heissen das nimmand mit der soft ware allein was an fangen kann. den sie kann keier logig verarbeiten.
Ok, hier hast du dir ja irgend etwas mit der Datenbank überlegt, in der du das Verhalten speicherst? Aber ich bin der meinung, dass diese Datenbank als Addon implementiert sein sollte, damit man sie nicht unbedingt benutzen muss. Ich zum Beispiel möchte lieber Code schreiben.
es sein den er nimmt das was wir standart mäsig mch für der seriale schitstelle.
Jein. Jetzt kommen ein wenig die Begriffe durcheinander. Wenn man nur die main control hat, dann ist das so. Aber die ganze Software besteht natürlich noch aus Addons von uns.
OK, das mit dcem Script und der Datenbank klingt gut, aber ich weiß nicht genau, wie das mit der Datenbank laufen wird. Ich werde nochmal deine alten Posts lesen. Aber wie gesagt, das würde ich als Addon einbauen. Sonst gehört die Datenbank zum Grundstock, und das würde bedeuten, dass es Einschränkungen bei der Plattformunabhängigkeit (ich denke jetzt an PDAs) geben würde. Aber sonst ist die Idee gut, ich habe sie ehgrlich gesagt erst jetzt verstanden.
So unterschiedlich ist das alles vielleicht wirklich nicht ;-)
Gruß
Johannes
Johannes
12.06.2004, 15:49
...
MrNiemand
12.06.2004, 15:50
last gast post is mine ;)
zumindest von numberfive weis ich das er eine funktionierende rs232 verbindung hat, wer kann da noch mithalten?
jeder könnte meiner meinung nach mal einen vorschlag machen, wie man es am dümmsten machen könnte (ein grobes protokoll) wie der uc die daten übertragen soll, denn einfach alle werte hintereinander ist quatsch!
mein vorschlag: der uc muss die daten eh irgendwo gespeichert haben, man kann die adresse aus der es gelesen hat als "variable" für den pc mitübertragen
andere variante: werte übertragen mit trennzeichen und auf beiden seiten definiern welcher wert wo steht!
Johannes
12.06.2004, 16:12
was meinst du mit
>zumindest von numberfive weis ich das er eine funktionierende rs232 verbindung hat, wer kann da noch mithalten?
Ich habe auch eine funktionierende Verbindung vom Mincrocontroller zum PC. Sogar auf Multithreading-Basis auf der Seite des Mikrocontrollers (CC2):
http://www.mindrobots.de/cc2/com.html
ZUm PDA, ich rede natürlich nicht einfach darüber, ich habe so ein Teil und es auch schon programmiert. SO ein gerät hat 400Mhz und so schnell kommt man nicht an seite Leistungsgrenze. Es ist auch nicht die Rede von dem Einsetzten des Displays ("außer man will abnehmen und dem Robi hinterherlaufen um "Stopp anzutippen"").
Wie der Mikrocontroller die Daten an die Software üpbergibt, sollte meiner Meinung nach dem Benutzer überlassen sein und nicht in der Hauptsoftware integriert sein.
Gruß
Johannes
Johannes
12.06.2004, 16:25
Ich verstehe das Problem ehrlich gesagt nicht, wie sehe auch noch nicht die Kritikpunkte. Es gibt einen Grundstock: main control und ein Bussystem zum Beispiel TCP.
Und jetzt gibt es Addons, die einfach hinzugefügt werden. Dafür könnte es dann irgendwie ein Tool geben, dass das macht. Und je nach Hardware der Benutzer installiert man sich das entsprechende. Wo ist da ein Problem? Wir können, wenn der grundstock steht, wieder auseinander gehen und jeder entwickelt Addons, wie er sie sich vorstellt. Das ist doch toll! Oder nicht? ;-)
Gruß
Johannes
MrNiemand
12.06.2004, 18:14
wenn es so einfach ist dann mach mal ;)
wo genau willst du denn den pda einsetzen? ich weis ja nicht wieviel geld du hast aber ich kann mir net einfach mal nen 400mhz pda leisten aber egal ;)
soll ja ingesamt keine kritrik sein nur eine konkretisierung. Ich dachte halt das Protokoll erstmal zu definieren wäre ein Einfang, denn das Prog soll ja leicht erweiterbar sein oder nicht? und ich glaube wenn man da mit einem komplexen Teil anfängt gibt es da Probleme!
Poste doch einfach mal wie du es dir konkrekt vorstellt. Platformunabhängig wäre es ja auch durch sql. Und wer seinen PC onboard mitnehmen will macht einfach Funk zu kabel!
du nimmst als beispiel tcp:
wie willst du dei daten vom uC per tcp zum pc bringen? wie gesagt wlan module sind teuer und ein pda der wirklich was taugt auch
NumberFive
12.06.2004, 18:33
Hallo johannes
schön das es jetzt doch weiter geht.
und das du es doch sieht das wir nicht so weit auseinader liegen.
Ok den den script interpreter und die db an bindung könnte man natürlich auch al addon bauen. kein frage. aber ds würde die koplexität am anfag für alle massiv erhöhen. und natürlich den faktor beweglichkeit von der platform ein wenig ein schänken. ein mysql wird nicht auf ein PDA laäfen ds ist war braucht sie aber auch nicht der kann auch auf einmpc laufen den der komuniziert ja schon mit tcp mit mir. das der script in de db liegt habe ich nur aus performens grunden gemach lässt sich schneller laden ab einer bestimmt grösse und ist so mit im lauf auwechsel bar was bei ein daeti wo sie auch immer liegt nicht so einfach währe.
Nun zu den protokollen und war ich so auf tcp abfahre es kann in zwischen einfach jetzt got er denkliche teil von PDA bis zum groß rechen jeder.
Wie funktioneirt TCp wenn du es genau wissen willst ehrlich gesagt kauf dir ein buch den ich weiß es auch nicht so genau. Aber im prinzip
läuft es so es werde paket gemach und die byte mit ein adrees ver sehen und ada auf die reise geschick. dei teil brauch uns aber nicht zu interesiieren den das machen die betiebs systeme. so wie läuft es bei mit
ich rufe eine funktion auf die heist connect die bekommt die adresse und den port mit alles bei mir 192.168.1.1 port 40000 wenn der connect zu stande kan meldet das betriebs sytem mir. in jave ich die funkt glaube ich blockieret aber egal. dan kann ich einfach byte ketten dem andere schicken das betriebs sytem mach den rest. das betriebs system schick alles einfach weiter den die beiden seite müssen wissen das da kommt.
Dein Webbrowser macht das zu beispiel auch so dann kommt die html seit als byte stream. dei rechner kann damit auch nix anfangen aber der broweser schon. und so kann es mein MessageCatcher
die ersten zwei bytes bestimme die länge die da kommen muß
so lange die nicht erreicht ist werden die daten nicht weiter geben
wenn die länge erreicht ist werde die länge byte ab geschieten und der rest wir der verarbeitung zu gefügt
Beispiel 0A am an fang würde heist da komme jetzt 65bytes an text.
die 0 schreib ich nur damit ma sie sie de ein 0 byte kann ich ja nicht darstellen hier im forum oder wie es ein c programmier schreiben würde 0x00 0x41
der rest sieht da halt so aus TEXT|TEXT|TEXT
das wird dann von mit inter pretiert. soll ich mal ein tcp server schreiben und du mail das du teste kannst ?
So ein ab schliesende fragen was spricht also da gegen wenn ic a mein projekt so weiter verfolge halt mich bei der addon geschichte genau an dir hier gemacht spezification. erweiter ihn so das er den script end weder per datei oder auf der datenbank lesen kann. Dann schlagen wie zwei fliegen mit ein klappe es gibt erlativ schnell software für die leute die ein pc einsetzen mti window jeder der ein addon schreiben möchte kan da schonanfanegn egal in was auch immer. und wir sehen realtiv schnell
ob die brobel lösbar sind. In der version 2 nehem wir den script interpreter und die die db an bindung rau und bauen davon addons und da konnem wir protieren. wisse aber schon wo ra es ankommt.
für die PDA einätze brauche wir dann ein addon aber so schlimm wäre das sicher nicht.
Ist nur ein vor schlagt
Also ein gutes Konzept ist meiner Meinung nach auch das wichtigste. Ich programmiere schon ziemlich lange und weis aus leidvoller Erfahrung, daß man nicht einfach drauf losprogrammieren kann. Das führt letztendlich dazu, daß man alles wieder nacher umbauen darf, was viel mehr Zeit kostet als wenn man sich die Sache vorher etwas genauer überlegt. Manchmal brauche ich auch Tage bis ich eine Sache durchdacht und mehrmals darüber geschlafen habe, bis ich eine Lösung gefunden habe. Das ist dann so ne Art AHA-Effekt.
Also was ein Grundlegendes Konzept angeht schließe ich mich da Johannes an. Mir ist das ganze auch noch ziemlich verworren, da jeder eigene Ideen hat die er durchsetzen möchte und wir da kein klares Ziel und auch kein durchdachtes Konzept haben.
-----
Natürlich kann ich NumberFive verstehen, daß er seine Idee und das was er bisher programmiert hat nicht aufgeben möchte. hat ja alles auch ziemlich viel arbeit gekostet.
-----
Das Hauptproblem dürfte aber hier wohl eher die Zeitliche Perspektive sein.
NumberFive, Du hast da einen konkreten Zeitrahmen in dem Du das ganze realisieren möchtest. Das mag für ein Projekt in einer Firma wichtig sein, aber als Hobby ?
Denn ich sehe das ganze als Hobby und habe da keine wirkliche Eile. Warum soll man sich den Stress machen ? Man hat ja schließlich auch noch andere Sachen zu tun. Und ein richtiges Konzept entsteht nicht von heute auf morgen, das will schon durchdacht sein. Je einfacher das Grundkonzept, desto flexibler ist das ganze nacher auch.
Aus Erfahrung muss ich sagen: Je einfacher desto besser.
Wir haben da ja keinen wirklichen Termindruck, ausser dem den wir uns machen. Lasst uns die Sache einfach in Ruhe angehen.
Was andere inzwischen auf die Beine stellen ist für mich nicht wirklich von Bedeutung. Vielleicht kann man da die eine oder andere Idee übernehmen. Warum nicht ?
Wie oft habe ich schon Systeme entwickelt die von anderen Systemen abgelöst wurden oder einfach nicht mehr gebraucht wurden. Das sehe ich nicht so tragisch.
-----
Was mir momentan fehlt sind einfach klare Ziele was das Ding nacher können soll. Am besten man überlegt sich mehrere Szenarien wie man das ganze nacher einsetzen möchte.
Wenn man diese hat, kann man sich daran machen zu versuchen das ganze unter einen Hut zu bringen. Dacher spricht mich die Idee mit einem zentralen Kommunikationsprotokoll am ehesten an, da das dann mehr eine Plattform ist, die völlig losgelöst ist.
Selbst wenn man dann etwas programmiert, muss es nicht immer unbedingt was sein, wo man sichtbare Ergebnisse hat. Ich programmiere oft Sachen die keine direkten Ergebnisse liefern aber eine wichtige Grundlage für andere Sachen bilden. Also mehr so ne Art Fundament für Weiterentwicklungen, welche sich dann wesentlich schneller realisieren lassen. Also schon mehr auf die Art : alles Kapseln und in Klassen packen.
So als hätte man einen Betrieb mit lauter Angestellten die für bestimmte Aufgabenbereiche zuständig sind und nichts anderes machen.
-----
Andere mögen weiter sein, aber wenn die Sache nicht offen und erweiterbar ist, hat man bald ein sogenanntes Legacy System, welches dann wie ein Dinosaurier zum sterben verdammt ist. Das gleiche passiert mit Projekten bei denen keine klaren Ziele definiert sind und jeder einfach mal drauf los arbeitet.
Das heißt nicht, daß man zwischendurch die Ideen nicht evaluieren muss.
Ich konnte noch nie ein ganzes System entwerfen ohne mich an den Computer zu setzen und einzelne Ideen auf realisierbarkeit zu überprüfen.
D.h einfach auszuprobieren ob man das machen kann oder nicht.
------
Was Linux und Java angeht, so ist das für mich mehr eine Sache des weiterlernens. Eigentlich will ich mich schon lange mit Linux auseinandersetzen, aber ohne einen realen Bedarf zu haben, also ein Ziel, funktioniert da bei mir nicht.
Für mich spielt dann dieses Projekt sozusagen der Antrieb um sich da überhaupt mit was neuem zu beschäftigen.
------
So jetzt ist gut, irgendwo habe ich den Faden verloren.
Ups, ich glaub ich hab da ne ganze Seite nicht gesehn.
Uff, das ist aber verdammt viel zum lesen, da ist ja schon wieder der halbe Abend rum.
@Johannes: Ich les mir erstmal Deine Arbeit durch damit ci da mal ne Idee davon bekomme.
NumberFive
12.06.2004, 19:41
hallo marten
natürlich habe wir zeit keine frage der termin hat mit der firma nix zu tu es es ein kontest andem ich gern da sein möchte das ist alles. was die erweiter barkeit angeht hast du sicherlich recht da muß man uaf passe das man nicht zu dino wird. aber du schreibts doch genau ds ich meine
du sagt du schreibst klasen dei man hinter weiter verwenden kann genau das ist doch meine ansatz nur das ich die halt jetzt schon in ein prg packen damit ander damit soielen können und es vertehen was ge meint ist.
das man sich ein engt wenn dann die schnittstelle so defienrt
Die Maincontrol stelle ein TCP port bereit an den der text übertragen wird
wobei in die ersten zwei bytes die länge angeben.
Das format ist mit sicherheit für alles offen oder nicht ?
Der text würde dann nach meiner defintion dann so aussehen:
SPEAK|Text der MessagesCatcher spricht den angeben text
RUN| der MessagesCatcher straten den internenen Script interpreter
SET|Variable|wert ein variable wir mit den dem wert versehen
wenn DB = true dann wird der wert auch gleich zeitig
die db geschrieben
die list kann man zu jedem zeit punkt erweiter un würde auch so schnell nicht an ihre grenzen kommen dene ich.
Weil Marten immer von ziel spricht hier meine für die projekt:
Script interpreter auf grund von daten Funktionen aus zu lösen
wo bei ein teil der funktioen im MessagesCatcher drin sind.
Bereitstellung Eines tcp server der der medudung entgegen nimmt
und der script interprter starten kann und ein verbindung zu mysql hat.
Also wenn jemad eine neu funktion haben will die der MessagesCatcher nicht zu ver fügnug stellt kann er sich ein fach per tcp daten zu kommen lassen wenn von controle ein variable ein bestimmten wert hat.
würde dann so aus sehen :
vom Sensor Watch kommt
SET|SENSOR01|50|
RUN|
im script stehen
IF SENSOR01 = 50
Send ADDON du sollst arbeiten
ENDIF
wenn die dieser stelle wird an den de teil der sich mit den name ADDON regetry hat der "text du sollt arbeit" geschikt
so stelle ich mir das for also in mein kein dino aber ich warte auf eure antworten.
Gruß
NumberFive
12.06.2004, 19:44
nach trag kon die telegramm hat zeit problem die sich abe glaube lössen lassen. es draf in den daten kein PIP zeich vo kommen und kein 0 byte aber das das kennt ja jeder c programmiere.
Gru0
Johannes
12.06.2004, 20:07
Moin,
ich stimme dir, matren voll und ganz zu, alles war du geschrieben hast kann ich nur bestätigen. Ich setze dich gleich mal auf meine Freundesliste ;-)
@MrNiemand
Du stellst es ein wenig so dar, als hätte ich hier überflogene Ideen. Es ist jedoch so, dass ich drei Jahre an einem Thema gearbeitet habe, das sich genau mit solcher Problematik beschäftigt. Du kannst die Arbeit auf meiner Website runterladen und dir mal einen Eindruck verschaffen.
Da wir bei unserem projekt von Volkswagen gesponsort wurden, habe ich für meine Roboter vielleicht überdurchschnittlich viel Geld, obwohl ich noch Schüler bin. Jedoch muss ich sagen, dass ich die Software, über die wir hier reden, primär deshalb mache, weil ICH sie verwenden möchte. Ich investiere keinte Zeit in entwas, mit dem ich nichts anfangen kann. Ich habe konkrete Vorstellungen für ein nächstes Projekt, für das ich so eine Software programmieren wollte. Dass Numberfive jetzt eine ähnliche Idee hatte, ist purer Zufall. Ich kann euch aber sagen, dass ich das alles, wovon ich hier rede, auch benutzen möchte! Sonst kann ich mein Projekt nicht machen!
@Numberfive
schön, dass wir uns wieder verstehen :-) Ich habe ehrlich gesagt manchmal Probleme, deine Posts zu verstehen und muss sie deshalb mehrmals lesen, aber so sind wohl ein paar Missverständnisse entstanden.
Du bringst mich jetzt mit deinem vorletzten Post auf eine Idee, aber vielleicht meinst du ja genau dasselbe.
Wir definieren einen Kommunikations-Standard. Somit könnten dann Addons mit deinem und meinem "Grundprogramm" (dafür brauchen wir unbedingt mal einen Namen, dass was bei mir main control heißt) verwenden. Das wäre doch was, und keine muss von seinem Endziel abrücken.
Zum Thema TCP: Was ich meinte ist, ob jeder Prozess auch irgendwie eine ID bekommt. Also, du hast 3 Programme auf einem PC und möchtest dem einen davon was schicken. Muss man eine ID o. Ä. angeben, die dieses Programm kennzeichnet? Oder bekommen alle Programme die Daten per TCP und jedes muss gucken, ob die Daten für ihn bestimmt sind?
Gruß
Johannes
Johannes
12.06.2004, 20:09
Unter Kommunikationsstandard verstehe ich übrigens erstens die Einigung auf eine Übertragungsart (z.B. TCP) und die Zusammensetzung der Daten. Also, was für Adressen mitgesendet werden, wo die Daten stehen etc. Ich werde mir da mal was überlegen.
Gruß
Johannes
MrNiemand
12.06.2004, 20:18
jetzt sind wir uns denk ich mal alle wieder einig, Numberfive erklärt mir gerade genauer was im Moment bei ihm vorhanden ist usw.
aber wäre es nicht einfacher das jeder das selbe grund prog (können aber vershciedenes os sein) hat nur verschiedene addons
Johannes
12.06.2004, 20:39
ja, aber dann kommen wir uns nicht überein ;-) Unsere Vorstellungen für diese Grundsoftware scheinen nicht vereinbar zu sein, jedenfalls jetzt noch nicht.
Gruß
Johannes
MrNiemand
12.06.2004, 21:11
wo liegen denn die großen unterschiede? ich denke wenn ihr wie du vorschlägst gemeinsame addons nehmen wollt müsst ihr euch eh aufeinander zu bewegen und ja näher das an der grundidee ist desto besser. Da kann ich ja evl etwas vermitteln, denn ich bin da neutral denn ich habe keine Grundsoftware O:)
@Johannes:
So ich habe deine Arbeit jetzt gelesen. War sehr verständlich erklärt und recht einfach zu lesen. Das Konzept mit den Treibern und Plugins hat mir recht gut gefallen. Einfach, funktional und wie mir scheint recht flexibel.
----
Ich denke das wir uns prinzipiell darauf einigen können TCP/IP als Übertragungsprotokoll zu verwenden (sei es auch das mir keine Alternative bekannt wäre).
----
Was das Telegrammformat angeht stellt es ja bereits eine Grundidee eines Kommunikationsprotokolls dar. Eine genaue Definition wie das ganze aussieht besteht zwar noch nicht, ist aber jetzt fürs erste nicht weiter wichtig.
----
Frage ist wer mit wem kommuniziert.
Nehmen wir einen zentralen Master, an den alle senden und von dem alle Addons / Bauteile ihre Befehle erhalten, oder kann jeder mit jedem kommunizieren.
Wenn man einen Master nimmt, können die Slaves natürlich auch miteinander kommunizieren indem der Master diese Daten einfach weiterreicht.
Zu bedenken ist in diesem Zusammenhang, das auf IP und Portebene arbeiten, also eher immer nur eine Verbindung zwischen zwei Komponenten haben und ein "Rundschreiben" so eigentlich nicht vorgesehen ist (ist zwar möglich, frage ist aber ob man das benutzen möchte).
Vorteile sehe ich eigentlich beim Master-Slave System insoweit als man einen zentralen Punkt hat an dem man die Kommunikation einfach mitverfolgen/protokollieren kann.
NumberFive, Du hast da eigentlich schon ein bestehendes Konzept, das mit seinem Telegramm-Protokoll eigentlich Plattformunabhängig ist. Ich habe da aber noch nicht so ganz durchgeblickt. Werde mir mal Deine Skizzen un d Deine Postings nochmal durchlesen. Ich versuche das dann mal zusammenzufassen ob ich das dann alles richtig verstanden habe.
! Die Idee mit den Variablen und den Bedingungen sind bei euch beiden ja recht ähnlich. ! Zumindest ist die Grundidee ziemlich ähnlich.
MrNiemand
12.06.2004, 21:36
also ich sage auch ein zentraler Master wäre das beste, eben das Prog was die Daten die reinkommen verarbeitet und gegebenenfalls in die DB schreibt.
Zumindest ist die Grundidee ziemlich ähnlich.
genau das sage ich ja auch, deswegen ahlte ich eine Grundsoft für das sinnvollste inder dann der komplette Umfang zum größten Teil in Addons steckt, so muss eigenltich keiner irgendeinen Teil seiner soft wegschmeißen sondern kann es einfach in ein Addon packen und fertig.
So z.b. wollte Numberfive mir seine grundsoft schicken, aber dazu brauch ich erst die Spreachausgabe die hat 68MB. Ich für meinen Teil brauche keine Sprachausgabe und habe nur ISDN, also würde ich gerne auf dei SPrachausgabe verzichten. => Optimales Addon
Johannes
12.06.2004, 21:50
Die Unterschiede liegen z.B. in der Programmiersprache. Aber vielleicht ist es gar nicht schlecht, sagt mal, wenn wir mehrere Versionen programmieren, wenigstens fürs erste? Dann können wir ein paar Erfahrungen sammeln, besonders ich, da ich ja noch nicht der Spezi in TCP bin.
Aber gut, dass wir jetzt einen Vermittler haben, ebenfalls willkommen im Boot, MrNiemand ;-)
Gruß
Johannes
Johannes
12.06.2004, 22:01
jetzt habe ich auch Beiträge übersehen, dieser Thread ist zu frequentiert! ;-)
MrNiemand
12.06.2004, 22:08
mehrere Versionen sind eine sehr gute Idee aber zumindest die Grundsoft sollte meiner Meinung nach einheitlich sein, sonst wird es evl. zu verzweigt. Alternative zwei Grundsofts die dann sogut wie gleich sind bis auf die Sprache ;)
@Johannes:kannst ja gerne mal ne grundsoft uppen dann können wir mal vergleichen was bei jdem gut und was schlecht ist!
betreff tcp: ich würde fast vorschlagen das TCP am besten bei Numberfive liegt bisher von den aktiv beteiligten im Thread, denn er hat da ja schon mehr gemacht.
wie wär es wenn ich auf meinem webserver ne db aufmach in der ihr dann eure soft testen könnt? einfach ne tabelle für jeden user oder so?
dann können wir das format der db direkt vergleichen.
oder schlägt jemand auch was anderes als eine sql db vor?
Johannes
12.06.2004, 22:10
So, jetzt bin ich wieder auf dem Laufenden. Ich kann euch beiden nur zustimmen. Nur, ich bin mir noch nicht sicher, ob ein Master sinnvoll ist, jedenfalls passt er nicht unbedingt in mein Schema. Denn, wie ich schon geschrieben habe, wäre es theoretisch möglich, dass man bei einer WLan-Verbindung den TCP-Bus direkt an dem Gateway anpackt und nicht über ein Addon. Das würde aber bedeuten, dass nicht mehr klar ist, wo der gemeinsame Master ist.
Also, der Kontrollrechner und der Roboter haben beide ja einen eigenen TCP-Gateway. Wenn jetzt aber die Gateways zusammengelegt werden, was ich befürworte, dann ist ein gemeinsamer Master nicht mehr logisch.
Es sei denn, man unterteilt den Kram in Ebenen. Also, wenn ein Addon des Roboters mit einem des Pc "reden" möchte, ginge die Nachricht erst zum Master des Roboters, dann zum Master des PCs und dann zum anderen Addon. Ist logisch, aber vielleicht kapazitätenfressend. Würde man eine direkte Kommunikation zwischen Addons erlauben, könnte ein Addon des Roboters auch direkt mit dem des PC kommunizieren.
Versteht ihr, was ich meine? Sonst sagt Bescheid und ich probiere es nochmal. ;-)
Gruß
Johannes
Johannes
12.06.2004, 22:13
So, schon wieder eine neue Nachricht...
@MrN*
>@Johannes:kannst ja gerne mal ne grundsoft uppen dann können wir mal vergleichen was bei jdem gut und was schlecht ist!
Im prinzip ja, aber kann noch dauern, da ich noch etwas Einarbeitungszeit in TCP brauche.
MrNiemand
12.06.2004, 22:14
ich versteh es ehrlich gesagt nich (schief zum bier nebenan kuck ;)
Johannes
12.06.2004, 22:17
Also, du bist ja gerade online, dann probiere ich es nochmal.
Also es gibt ja zwei Möglichkeiten, entweder können generell Addons untereinander kommunizieren oder immer nur über einen Master. OK?
MrNiemand
12.06.2004, 22:23
hast du icq dann können wir des da bereden mei nummer 120040916
Johannes
12.06.2004, 22:28
OK, ich schicke dir mal so nen Request...
NumberFive
12.06.2004, 23:18
So leute muß erstmal nach lesen was ihr so gepostet habt.
matern du bist leider von dem folgende ein wenig ausgeschloss da ich den mail adresse nicht habe.
So ein Prebeta habt ihr bekommen. nur um einfach zu zeigen das es geht
gleich vorweg es sind nicht alle befehle drin und dir komunikation ist nur zur remote per tcp. Die anderen zwei reden über com mit einander
aber das war auch auf mein bild so.
Der SensorCatch habe ich zu test tool umgebaut Das heist der hat
auch eine eingabe zeile damit man die telegramm rein schreiben kann zu testen des weiteren kann er von der rs232 folgendes lesen
A2byteE wenn er dast verstanden hat schreibt er A255 als byt wert 2xE
zurück also der controller geht eigendlich auch schon dran.
Die RemteControl (RoboClient.Exe) kann zur zeit nur einen befehl schicken
(HOLD) an sonsten zeig die inbisschen was an.
der MessagesCatcher stellt alles zu verfügung. konfiguriert wird alles
per ini dateien die werden bei ersten starten erstellt.
Starten MessageCatcher
SensorCatcher
und wen ihr was sehen wollt Roboclient
wird aber für die funktion nicht benötigt.
Tabellen und so finden ihr in der zeiten mail da ist auch der script drin den er inter pretiern kann.
EDit: damit man es besser lesen kann
Johannes
13.06.2004, 13:58
Moin Numberfive,
ich werde mir in der nächsten Woche einen SQL-Server beschaffen, damit ich dein Programm ausführen kann.
Habe gerade deine Mail bekommen und werde jetzt mal durchlesen und antworten.
Gruß
Johannes
Anbei nun das programm das interpretiert werden kann:
insert into PrgCode (RunningNumber,Code) values ( 0,'IF SENSOR01 = 01');
insert into PrgCode (RunningNumber,Code) values ( 1,'Trace war gleich');
...
Hallo,
ist diese Methode noch aktuell? Wenn ja, würde mich interessieren, warum du das so umständlich handhabst und jede Zeile einzeln in die Datenbank wirfst.
Zum einen sind Änderungen nur sehr schwer und unübersichtlich zu realisieren (Zeilen löschen, umnumerieren, alle Zeilen anzeigen lassen ect.), Erweiterungen des Programms noch umständlicher einzufügen und zum anderen benötigst du doch sowieso einen Parser, um die Befehle zu erkennen. Warum diesen Parser dann nicht um die Kleinigkeit erweitern, das er freien Text erkennen kann?
Apropos, bei dem von mir gequoteten Beispiel oben, die zweite Zeile ... was soll der Parser damit anfangen? Da steht kein Befehl drin, nur etwas Text, was er wohl ausgeben soll ...
Just my 2 Cent
Andreas
NumberFive
13.06.2004, 15:22
Hallo ads,
ja das ist aktuell. Ok es währe möglich chr(10)chr(13) als
zeilen ende fest zu schreiben leider mach das die nur auf wändiger
und es brin nix da im mysql die vrachrspaltt ein maximal länge von 255
zeich hat also finde ich das es nicht den auf wann wert ist.
ja die zweite programm zeil heis nur das er halt was trace soll
die habe ich ei gefügt bei test ob der if funktionier was stört dich dran ?
Wenn die RemotControl an gemeldet sit sieht du dies auf gaben und weiß von der script gerade steh also ein art deggung.
in eine echten sytem würde hier sicher ein an weisung stehen
Urgs, sorry, schau doch bitte noch mal über deine Antwort drüber, ehe du sie abschickst. Das sieht mir fliegend geschrieben aus und ich musste das ebend 3 mal durchlesen, ehe ich mitbekommen habe, was du meinst.
Nein, die Frage ist nicht, ob Blob oder Char oder Varchar in Mysql oder was für ein Zeilenende Zeichen, die Frage ist grundlegend: warum überhaupt eine Datenbank für den Programm Text?
Wie stellst du dir Änderungen im Programm vor? Indem du jedesmal das Programm neu in die Datenbank einspielst? Indem du Änderungen direkt in der DB vornimmst? Hast du schon Vorstellungen, wie du das lösen möchtest?
Meiner Meinung nach ist es zuviel Aufwand, das in eine Datenbank zu schreiben, um es dann einmalig auszulesen. Wenn du das in einem Textfile lässt und von dort parsen tust, kommst du mit wesentlich weniger Aufwand davon.
Eine Datenbank ist ok, wenn sich die Daten ändern. So oft ändert sich dein Programmtext aber nicht, wenn er einmal fertig ist.
Zu der zweiten Zeile aus dem Quoting: war nur so eine Frage, ich dachte mir schon, das es bloss ein Demo ist. Wenn du das als fertiges Programm hättest, wäre "Trace" dein Schlüsselwort und er müsste irgendetwas damit anfangen können. Hier fehlt wohl eher ein "print" oder "echo" davor, oder? ;-)
Bye,
Andreas
NumberFive
13.06.2004, 17:43
Hallo Andreas,
ok das letzte Postin war wirklich grausam werde besserung geloben.
Ich gebe zu nur für den quelle code des scriptes war die db sicherlich
mit kanonen auf spazen geschossen. Aber sie soll naher ja noch mehr machen was seit heut drin ist das die variable dort in kopie abgelegt werden.
und was auch klar ist es wird ein version ode db geben aber die hat dann bestimmt funktionen nicht.
Gruß
Johannes
13.06.2004, 20:00
Ich habe mich jetzt nun mit Numberfive geeinigt bzw. wir haben festgestellt, dass wir doch sehr ähnliche Ziele verfolgen. Wie das Projekt weitergeht, werden wir euch demnächst mitteilen.
Gruß
Johannes
Johannes
13.06.2004, 23:34
http://dev.mysql.com/get/Downloads/MySQL-4.0/mysql-4.0.20a-win.zip/from/pick
Hier findet Ihr den passenden SQL-Server für Numberfives Programm. (Der Link ist in erster Linie für mich, da ich das Teil in der Schule runterladen will und dafür die URL irgendwo speichern wollte...)
Gruß
Johannes
Johannes
18.06.2004, 16:54
So, obwohl dieser Thread etwas eingeschlafen ist, sind wir schon ein gutes Stück vorangekommen. Alles weitere werdet Ihr auf unserer Website zum Projekt erfahren:
http://www.mindrobots.de/jn5
Demnächst werden mehr Infos folgen.
Gruß
Johannes
NumberFive
24.06.2004, 22:41
Hallo Leser,
wollte nur mal kunt tun wir arbeiten kräftig an der software
die ersten versuche laufen.
Gruß
Johannes
10.07.2004, 22:08
In den nächten Tagen werden wir einige Informationen zum JN5-Projekt auf http://www.mindrobots.de zur Verfügung stellen. Wir hoffen auf reges Interesse und Mitarbeit.
Gruß
Johannes
Johannes
22.08.2004, 15:50
Die erste BETA-Version ist nun fertiggestellt und kann auf http://jn5.mindrobots.de runtergeladen und getestet werden. (auf der Seite ganz nach unten Scrollen auf auf RELEASE: MCJAVA BETA 1 klicken.)
Gruß
Johannes
NumberFive
22.09.2004, 07:05
Bei versionen und Test addons stehen jetzt auf der Projeckt seite also down load zu verfügung.
Johannes
15.05.2005, 18:56
Moin,
es gibt ein paar neue Infos auf unserer Website:
http://smirs.mindrobots.com
http://www.mindrobots.de/public/banner/smirs.gif
Gruß
Johannes
Johannes
29.05.2005, 11:53
Nun gibt es einen Guide, besser gesagt eine Schritt-für-Schritt-Anleitung, mit dem/der ihr ganz einfach die Funktionsweise von s²mirs ausprobieren könnt. Im Downloadbereich befindet sich momentan die aktuelle Version der Main Control CENTRAL 1.0 (beta 2805, auf Java basierend), ein Testmodul, mit Microsoft VB.NET programmiert, sowie eine .NET DLL, mit der sehr schnell Module für s²mirs programmiert werden können.
http://www.mindrobots.de/cgi-bin/read.cgi?section=algorithms&site=2-3-1&action=readsite
http://www.mindrobots.de/cgi-bin/read.cgi?section=algorithms&site=2-1&action=readsite
http://smirs.mindrobots.de/
Kommentare sind erwünscht!
Gruß
Johannes
Hallo,
ich muß zugeben, ich habe eure Webseite erstmal nur überflogen. Aber irgendwie musste ich dabei immer an CORBA denken ... ich nehme an, CORBA ist euch bekannt? Könnt ihr kurz die Unterschiede / Gemeinsamkeiten zwischen s2mirs und CORBA umreißen?
Johannes
06.06.2005, 22:31
Moin,
CORBA sagt mir im Moment nichts, da müsste ich mal recherchieren.
Gruß
Johannes
Na dann nur schnell ein paar Links
corba:
www.corba.org
http://www.cs.wustl.edu/~schmidt/corba-overview.html
darauf aufbauend (speziell für Roboter)
http://smart.informatik.uni-ulm.de/MIRO/index.html
was ähnliches (ohne corba):
Player/Stage: http://playerstage.sourceforge.net/player/player.html
Johannes
06.06.2005, 23:22
Hm, hab im Moment wenig Zeit, aber ich kann dir nochmal ein paar Stichworte zu unserem System geben.
- alle module sind einzelne Programme, die per TCP/IP kommunizieren
- die Vernetzung von mehreren Robotern und deren Synchronisation beim bzw. nach Abbrechen der Verbinmdung untereinander
- das ganze ist kostenlos
- ...
Sorry, ich erzähle gerne mehr darüber, wenn Interesse besteht, denn das wünschen wir uns ja. Ich habe allerdings die letzte Nacht wegen eines ganz anderen Projektes durchgemacht und muss dringend schlafen :-)
Wir können morgen weiterreden, vielleicht hast du ja dann etwas konkretere Fragen und ich schaue mir CORBA mal an.
Gruß
Johannes
NumberFive
19.06.2005, 08:30
Hallo zefram,
ja die Ähnlichkeit ist auf den ersten blick nicht ganz von der Hand zu weisen.
aber es gibt doch ziemliche Unterschiede. Cobra lässt das bauen von eignen Funktionen zu und ist praktisch ein Interface um Funktion irgendwo aus zuführen.
Bei smirs ist das anders und schon ein wenig spezieller es gibt fast kein Funktion sonder eigentlich nur Daten die sich ändern. Durch das ändern der Daten reagiert das System.
Die MC ist eine Art Datenspeicher wo jeder Daten holen und schreiben kann. Und kein Funktionspool. Das hat den Vorteil das man nicht dauert neu Funktion definieren muss.
Ich versuche es mal an einem Beispiel:
MC Befehle : SET|<VarName>|<VarWert>
Jetzt Schickt ein Addon :
SET|Hallo|3
wenn jetzt wird die Variabel Hallo mit dem Wert 3 belegt.
Wenn jetzt niemand damit was tut ist da ok oder wenn jemand auf diese Veränderung
hört passiert was in dem jeweiligen Addon. Aber was passiert definiert das addon nicht
die MC.
Bei mir gibt es 256 Variablen die den Daten Austausch mit dem AVR regeln.
Aber die Bedeutung der Variablen definiere ich erst im AVR Programm.
Das hat den Entscheiden Vorteil das ich immer erst im letzten Glied der Kette die Funktion
definiere. Anders rum genau so im Steuer prg werden nur bestimmte Variablen gesetzt
wenn ich das tuet aber was im Robi damit passiert ist nicht definiert.
Das mach das System sehr frei und erweiterbar. Habe noch nix gefunden was mit diesem
Prinzip nicht funktioniert.
Einige Addon's sind nur Datenmittler so zum Beispiel mein Serial Addon. Das auf die 256 Variablen hört und sie schreibt. Und eine Veränderung dann Serial überträgt in der Form A<ByteVarName><ByteVarinhalt><E>
Um es den Leuten etwas einfacher zu machen die TCP nicht können oder es nicht programmieren
wollen gibt es DLL's und beispiele/klassen die einem das Abnehmen.
TCP war die Wahl weil sprachen unabhängig und Rechner unabhängig Betriebsystem un abhängig.
So könnte man rein theoretisch eine Farm mit Rechnern für den Robi verwenden.
Ich hoffe ich habe dein Interesse geweckt. Und würde mich freuen wenn du dich mit dem System beschäftigst und bei der weiter entwicklung hilfst.
Mfg
Johannes
19.06.2005, 12:14
Moin,
ich hatte diesen Thread hier ganz vergessen. Numberfive hat es gut beschrieben. smirs ist eigentlich gar nicht auf Roboter beschränkt. Meine Version unterstützt beispielsweise die Vernetzung von mehreren Robotern, aber eine ganz andere Anwendung ist denkbar, die ich mal kurz beschreiben möchte. Die Idee dazu kam mir erst letztens.
Folgendes Roboter-ferne Problem. Ich habe eine DSL-Flatrate, die mehrere Rechner über einen Router nutzen. Der Router ist integriert in einem Switch. Die Flat ist volumengegrenzt und man muss aufpassen, dass die 2GB nicht überschritten werden. Der Router besitzt leider keine Funktion, die transferierten Bytes zu zählen. Der SpeedManager von der Telecom hingegen kann immer nur das zählen, was der eine Rechner transferiert. Es gibt jedoch mehrere Rechner, die das Internet nutzen. Man muss also immer die Werte aller Rechner zusammenzählen.
Mit smirs kann man genau das automatisieren, da dies ein passender Anwendungsfall hierfür ist. Es gibt Daten (transferierte Bytes), die mehrere Einheiten (Rechner) produzieren und die zusammengetragen werden sollen, ohne dass eine zentrale Einheit vorhanden ist. Es gibt also keinen Server, bei dem die Daten zwischengespeichert werden - es gibt eben nur die einzelnen Rechner, die sich hierarchisch auf einer Ebene befinden.
Das smirs System kommt nun folgendermaßen zum Einsatz. Auf jedem Rechner ist eine Main Control und ein Modul vorhanden, dass die Transfers zählt. Diese werden auf der MC gespeichert. Und das passiert auf jedem Rechner. Die Main Controls kommunizieren nun und tauschen ihre Daten aus, sodass jeder die Informationen der anderen Rechner hat. Möchte man nun wissen, wie viel transferiert wurde, müssen die Daten nur noch zusammengezählt und ausgegeben werden.
Ich hoffe ihr könnt es euch vorstellen. Mein Problem bei der Realisierung dieses Volumenzählers ist, die Datenmenge zu zählen, die vom Router kommt bzw. dort hin gesendet wird.
Gruß
Johannes
Hallo,
danke für eure Erläuterungen. Was mich noch interessieren würde: Ist es möglich s2mirs zum Datenaustausch zwischen einzelnen in C/C++ geschriebenen Modulen zu nutzen (über die DLL) oder geht das nur mit .NET? Und: Nutzt ihr oder ein anderer die Software auf einem realen Roboter?
Johannes
26.06.2005, 15:53
Moin,
wir beide werden die Software selbt auf unseren Robotern verwenden und dann natürlich Infos dazu geben.
>Ist es möglich s2mirs zum Datenaustausch zwischen einzelnen in C/C++ geschriebenen Modulen zu nutzen (über die DLL) oder geht das nur mit .NET?
Ich verstehe die Frage nicht ganz. Es ist prinzipiell egal, in was für einer Sprache die Module geschrieben sind, da sie unereinander mit TCP kommunizieren. Ich habe jedoch eine DLL geschrieben, die in einem .NET-Programm verwendet werden kann, sodass man sich auch um diese TCP-Sache nicht mehr kümmern muss. Numerfive hat soweit ich weiß eine DOM-DLL geschrieben, die das ganze für nicht-.NET-Sprachen übernimmt.
Gruß
Johannes
Genau das wollte ich wissen: Muß ich für mein C/C++ Modul noch extra eine Implementierung eures Protokolls schreiben oder gibt es dafür von euch schon was fertiges.
Johannes
27.06.2005, 01:38
Wie gesagt, dafür hat Numberfive soweit ich weiß schon etwas fertiges.
Gruß
Johannes
NumberFive
27.06.2005, 19:10
Ja ich habe eine com dll die einenm einges ab nimmt und da ist auch ein funktion zu zerlegen der Daten drin sollte also kein problem sehr schnell ein neues addon/modul zu schreiben.
wenn mein Robi läuft dann immer mit MC habe keine Andere software.
Alle versuche und erkennisse von mir sind immer mit dem MC prinzip.
Gruß
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.