Standart PC Software für Mobile Roboter

[NumberFive]

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]

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

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]

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]

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]

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]

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

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]

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)