Standart PC Software für Mobile Roboter

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

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.

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ß

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

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).

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');

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ß

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

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

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 ?

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

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 ;-)

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.

Hallo Johannes

Natürlich geht es dann weiter du hast mein "Kampf" Geist geweckt.

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

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

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 ?

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ß

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

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.

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

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ß

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

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

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ß

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

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 ,... .

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.

Bild hier  

Hier ein Beispiel (Roboter oben, PC unten. Beide haben die main control installiert, die plattformunabhängig ist.):
Bild hier  

Und nun zu der Programmierung:
Bild hier  

Gruß
Johannes

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.

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

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

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

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ß

So johannes

meiner ist auch nicht viel kürzer *g*

Gruß

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

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