Standart PC Software für Mobile Roboter

[NumberFive]

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]

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]

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]

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]

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]

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]

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]

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.

[matren]

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]

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