Als mehr oder weniger erfahrene Java-Programmierer habe ich es vor kurzem gewagt ein größeres C++-Projekt in Angriff zu nehmen, bei dem das Ziel ist einen Roboter autonom agieren zu lassen.
Leider habe ich einige grundsätzliche Verständnisprobleme was die Struktur des Gesamtprogramms angeht und wäre daher sehr dankbar, wenn ihr mir ein wenig helfen könntet den Überblick zu gewinnen.

Ich möchte eine größere cpp-Datei haben, die als eine Art Verwaltung agiert und auch die einzige main-Methode des gesamten Projekts hat. In den anderen cpp-Dateien werden zusammengehörende Methoden (z.B. für Dateizugriff oder Steuerung von einzelnen Roboterkomponenten) implementiert und per #include "Headerdatei.h" in den anderen cpp-Dateien verfügbar gemacht.

Die ersten Fragen, die mir so gekommen sind (bei weitem nicht die letzten ;-()

1. Wenn ich ein Objekt der Hauptklasse (Verwaltungs cpp) erstelle und mit diesem Objekt dann in den anderen cpp-Dateien auf die Methoden der Verwaltungs cpp zugreifen möchte, muss ich dann in jeder weiteren cpp ein neues Objekt der Hauptklasse erstellen oder reicht es wenn ich in den weiteren cpp-Dateien jeweils einen Zeiger auf das Objekt der Verwaltungsklasse habe?

2. Wie würde ich einen solchen Zeiger denn realisieren und in den weiteren Klassen dann deklarieren und benutzen? Z.B. möchte ich aus der Verwaltungsklasse dann eine Methode a() aufrufen.

3. Wie ist es wenn ich zwischen den einzelnen anderen Dateien Funktionen aufrufen will? Also ohne den Weg über das Verwaltungsobjekt zu gehen. Z.B. Zum Ansteuern eines Roboterarms benötige ich das Lesen aus einer Datei. Wie sollte das am besten realisiert werden? Vielleicht doch besser über die Verwaltungs-cpp oder einfach Objekte beider Klassen erzeugen und dann per Klasse.Methode() darauf zugreifen?

Vielen Dank für die Hilfe und entschuldigt die vielleicht ein wenig dummen Fragen, aber C++ ist halt doch ne andere Angelegenheit als Java...

1. ein DIN A0 blatt und viele kleine selbstklebende notizzettel holen
2. sich richtig gut zu überlegen, was für aufgaben welche klassen übernehmen.
   in etwa das interface von den einzelnen objekten entwerfen.
   -welche funktion ist nur für eigenen gebrauch bestimmt? (private?)
   -welche müssen überall aufrufbar sein? (public?)
   -evtl nur bestimmten klassen zugriffsrechte erteilen? (friends?)
3. welche komponenten müssen miteinander kommunizieren können?
   eifachste lösung: alles zentral machen [Verwaltungsklasse] und einen zeiger auf diese klasse in jedem anderen objekt speichern. Die einzelnen komponente als member-variablen der verwaltungsklasse deklarieren. So können alle komponenten sich gegenseitig indirekt über die verwaltungsklasse ansprechen (solange die friend-zugriffsrechte sinnvoll verteilt sind, gibt es eigentl kein riesenchaos)
4. evtl braucht man klassen, die jederzeit überall verfügbar sein müssen
   (Singletons) [benutze ich einzig und allein für die logfile, aber ohne logfile geht wirklich gar-nichts]

also, es gibt bestimmt bessere möglichkeiten, das ganze programm irgendwie zu strukturieren, aber das ist halt schon mal eine einfache möglichkeit, das größte chaos zu vermeiden.

in meinen programmen sieht es dann mehr oder weniger so aus:

//fwd declaration
class KuenstlicheIntelligenz; 
//...

class Verwaltung{
public:
  //alles andere als members
  KuenstlicheIntelligenz ki;
  Motorik motorik;
  Stromversorgung strom;
  //was weiß ich was...
};

class KuenstlicheIntelligenz{
 Verwaltung* verwaltung:  //zeiger auf die verwaltung

 //indirekter zugriff auf andere komponente:
 void f(){
  verwaltung->strom.ausschalten();
 }
};

//analog alle anderen components

selbstverständlich alles auf 12031030139170491 header und cpp's verteilt wenn's sein muss...

hoffentlich hilfts was

Jaja, das ist auch immer so ein Problem von mir: Ich leg immer mit der Programmierung los und mache mir dann nebenbei Gedanken über die Struktur und wer mit wem kommunizieren muss, obwohl ich weiß, dass das 100%-ig der falsche Weg ist!

Werde mir das mal endgültig zu Herzen nehmen!!

Ein weiteres Problem, dass ich beim ersten Post schon angesprochen habe:
Was mache ich, wenn 2 Klassen ohne die Verwaltungsklasse kommunizieren sollen?

Noch ein Problem:
Wenn ich in der Verwaltungsklasse eine Methode einer anderen Klasse aufrufen will erstelle ich am besten einen Zeiger auf ein Objekt der anderen Klasse innerhalb der Verwaltungsklasse und greife dann darüber auf die Methode der anderen Klasse zu, also ungefähr so:

innerhalb Verwaltungsklasse.cpp

AndereKlasse* ptrAndereKlasse;
ptrAndereKlasse->methodeDerAnderenKlasse();

aber was mache ich, wenn ich in einer weiteren Klasse wieder auf die methodeDerAnderenKlasse(); zugreifen will, aber dabei sicher sein will, dass ich auf das selbe Objekt (also mit den gleichen Werten bei den Parametern) zugreife??

Wenn ich dann wieder einen Zeiger anlege, zeigt der dann doch auf ein neues Objekt der Klasse, oder??

Dein Vorschlag verstehe ich allerdings nicht genau bzw. er ist als Lösung für dieses Problem nicht geeignet.
Wenn ich das richtig verstehe willst du hier eine Vererbung anwenden, aber bei meinem Problem haben die verschiedenen Klassen eigentlich nichts miteinander zu tun in dem Sinn, dass die eine eine Spezialisierung (und damit Unterklasse) einer anderen Klasse ist, sondern es soll lediglich ermöglicht werden, dass alle Klassen untereinander kommunizieren können...

Der zeiger auf die "verwaltung" in allen anderen klassen ist einfach da, damit man alle verknüpfungen irgendwo zentral bündelt: alle components haben zeiger auf die "verwaltung", "verwaltung" beinhaltet alle components. So muss man nicht in jedem component zehn zeiger zu anderen components speichern, damit sie miteinander "kommunizieren" können (funktionen aufrufen oder sonstiges)

Was ich in C++ noch nicht ganz verstanden habe, ist die Geschichte mit den Zeigern (das hat echt der Teufel höchstpersönlich erfunden).
Wenn ich jetzt in jeder der anderen Klassen jeweils einen Zeiger auf die Verwaltung erstelle (Verwaltung* verwaltung;), auf was zeigen die dann?
Es wurde kein Objekt von Verwaltung erzeugt, oder doch? Zeigen dann alle Zeiger aus den anderen Klassen auf dasselbe Verwaltungsobjekt????
Was bewirkt der Befehl Verwaltung* verwaltung; ??
Wird ein Objekt von Verwaltung angelegt, oder ermöglicht es nur einen Zugriff auf die Methoden und Variablen von Verwaltung, was ich mir ohne dazugehöriges Objekt aber nicht vorstellen kann.

Und wie sieht es mit Variablen aus, auf die alle anderen Klassen zugreifen können sollen? Dass man die nicht public definieren soll, habe ich auch schon begriffen. Also bleibt mir wohl nichts anderes übrig, als sie in der Verwaltungsklasse als private zu definieren und dann get- und set-Methoden dafür zu schreiben, oder gibt es dafür einen eleganteren Weg?

Und noch eine Frage: Wie sieht es aus mit privaten Variablen bei den anderen Klassen? Sagen wir, die Klasse Motorik hat eine Variable mit dem Namen

private double speed;

Wenn ich auf diese Variable in einer anderen Klasse außer der Verwaltungsklasse, also z.B. innerhalb von Stromversorgung darauf zugreifen will, wie mache ich das am besten?
Private Variable in Verwaltung anlegen?
Oder get- und set-Methode für die private Variable speed innerhalb der Klasse Motorik anlegen und dann per

verwaltung->strom.getSpeed()

darauf zugreifen?!

Langsam ergibt das Ganze Sinn! Danke!!

Zugriffe solltest du über Methoden machen. Das ist auch Kritikpunkt an dem Beispiel dort oben: über die Verwaltungsklasse wird KuenstlicheIntelligenz an ein 3. Objekt gebunden. Das führt zu Abhängigkeiten, die bei Änderungen sehr viel nach sich ziehen können.
Außerdem würde ich eine Protokollklasse für alle Module erzeugen. Dann kannst du diese nämlich sehr einfach austauschen.

Beispiel:

//Protokolklassen
class KuenstlicheIntelligenz
{
    Verwaltung* verwaltung;
    int some_member;

public:
    KuenstlicheIntelligenz(Verwaltung* __verwaltung)
    : verwaltung(__verwaltung)
    { }

    virtual void denken() = 0;
};

class Motorik
{
    Verwaltung* verwaltung;

public:
    Motorik(Verwaltung* __verwaltung)
    : verwaltung(__verwaltung)
    { }

    virtual void laufen() = 0;
};

class Stromversorgung
{
    Verwaltung* verwaltung;

public:
    Stromversorgung(Verwaltung* __verwaltung)
    : verwaltung(__verwaltung)
    { } 

    virtual void ausschalten() = 0;
};

//Gesamtverwaltung
class Verwaltung
{
    KuenstlicheIntelligenz* ki;
    Motorik* motorik;
    Stromversorgung* strom;

public:
    void attach(KuenstlicheIntelligenz* __ki, Motorik* __motorik, Stromversorgung* __strom)
    {
        ki = __ki;
        motorik = __motorik;
        strom = __strom;
    }

    void strom_ausschalten()
    {
        strom->ausschalten();
    }

    void denken()
    {
        ki->denken();
    }

    void laufen()
    {
        motorik->laufen();
    }
};

//Fabrikmethode zum Erzeugen des Roboters
template<class KI, class MOTORIK, class STROM>
std::auto_ptr<Verwaltung> erzeuge_roboter()
{
    Verwaltung* temp = new Verwaltung;
    temp->attach(new KI(temp), new MOTORIK(temp), new STROM(temp));
    return temp;
}

//Konkrete Implementierungen für Module
class DummerRoboter : public KuenstlicheIntelligenz
{
public:
    DummerRoboter(Verwaltung* __verwaltung)
    : KuenstlicheIntelligenz(__verwaltung)
    {}

    void denken()
    {
        verwaltung->strom_ausschalten();
    }
};

class KeineBeine : public Motorik
{
public:
    KeineBeine(Verwaltung* __verwaltung)
    : Motorik(__verwaltung)
    {}

    void laufen()
    { }
};

class LiIonenAkku : public Stromversorgung
{
public:
    LiIonenAkku(Verwaltung* __verwaltung)
    : Stromversorgung(__verwaltung)
    { }

    void ausschalten()
    {
        //sehr kompliziert!
    }
};

//Test"lauf"
int main()
{
    std::auto_ptr<Verwaltung> meinRoboter = erzeuge_roboter<DummerRoboter, KeineBeine, LiIonenAkku>();

    meinRoboter->denken();
    meinRoboter->laufen();
}

Wenn man will kann dem Roboter hier auch während des Betriebs ein neues Gehirn verpassen
Hier ist die Verwaltung nun aber noch nciht als Singleton implementiert. Das würde die Fabrikmethode und die Konstruktoren nochmal vereinfachen.

Edit: Konstruktoren vergessen.

Eine Frage, die spontan bei mir aufkommt:
Wie es der Verwaltung gelingt auf die verschiedenen Komponenten zuzugreifen ist mir dank der vorigen Erläuterugen nun klar

Aber: Wie sieht aus mit dem Zugriff von anderen Komponenten auf die Methoden der Verwaltungsklasse aus?
Es wird gesagt, dass ein Objekt erzeugt werden muss, damit ich auf dieses mit Zeiger zugreifen kann. Aber was ist, wenn ich jetzt in jeder Komponente einen eigenen Zeiger auf ein Verwaltungsobjekt anlege!? Dann zeigen sie doch auf verschiedene Verwaltungsobjekte, aber ich will doch, dass sie auf das IDENTISCHE Objekt zeigen, damit der Zustand der gleiche ist.

Wie mache ich das denn am besten?
Ein Objekt der Klasse Verwaltung lege ich doch erst in der main-Methode an?! Wie ist es mir dann noch möglich Zeiger darauf zeigen zu lassen?
Oder soll ich eine Methode innerhalb der Verwaltungsklasse schreiben, die die Adresse des Verwaltungsobjekt an die anderen Komponenten weitergibt?
In etwa so:
[cpp]
Verwaltung* getVerwaltung(Verwaltung verwObjekt)
{
return &verwObjekt;
}

und das dann in den anderen Methoden aufrufen? Oder sehe ich was komplett falsch?

Aber diese Methode getVerwaltung kann ich außerhalb der Verwaltungsklasse doch nur benutzen nachdem ich ein Objekt der Verwaltungsklasse angelegt habe benuten, aber genau das will ich ja nicht

Ich bin wieder ein wenig verwirrt

class Verwaltung
{
    Verwaltung(){} //Konstruktor privat, damit kein anderer eine Instanz erzeugen kann
public:
    static Verwaltung* get_instance()
    {
        static Verwaltung instance;
        return &instance;
    }
};

Aufrufe erfolgen dann so:

Verwaltung* verwaltung = Verwaltung::get_instance();
verwaltung->some_op();

//oder direkt:
Verwaltung::get_instance()->some_op();

Das ist die einfachste Variante von Singletons. Nicht threadsicher und nicht geeignet für Objekte, die eventuell beim Beenden des Programms nochmal benötigt werden (Log-Objekte).

Edit: Bei meiner Variante hat die Factory-Methode dafür gesorgt, dass die Module die richtige Instanz von der Verwaltung bekommen.

Das Problem ist aber auch, dass ich in Java noch kein größeres Projekt geschrieben habe. Das waren meistens kleine Furzprogramme, wo man maximal mal ne Vererbung oder so gemacht hat, daher sind mir viele der gängigen Konzepte leider nicht bekannt

Aber wie ihr selber schon gesagt habt: Wenn man es mal für eine Programmiersprache verstanden hat, dann kann man es auch auf andere anwenden und genau deshalb habe ich mich dazu entschieden. Ich hätte das Projekt zwar lieber in Java gemacht, aber für Java gibt es nur eine zusammengebastelte API, die wohl mehr Probleme verursacht als löst und daher musste ich jetzt C++ verwenden.

aber man braucht hat für das ganze ein bisschen disziplin und vor allem guten überblick über das, was man da tut. Hier können auch die tollsten dokumentationen für die sprachsyntax und die dicksten bücher nicht viel helfen. Man muss halt einfach ganz genau wissen, was man will. Wenn man das für sich ausformuliert hat, ist es kein großes problem mehr, das ganze in beliebiger sprache umzusetzen...

Dr.Ottel schrieb:

einen Roboter autonom agieren zu lassen.

und ..

Dr.Ottel schrieb:

Zum Ansteuern eines Roboterarms benötige ich das Lesen aus einer Datei.

Ich meine, das ist zu wenig, um irgend eine Aussage darüber machen zu können, wie man so etwas aufbaut. Aus Erfahrung weiß ich, dass eine übergeordnete Verwalter-Klasse die alle kennt und alle kennen im besten Fall die zweit schlechteste Lösung ist.
Komischerweise kommt am Anfang jeder genau auf diesen Ansatz - egal für welches Problem .

Daher meine Fragen an Dr.Ottel:
- wie ist der Roboter aufgebaut?
- was soll er genau tun; was bedeutet 'autonom agieren'?
- wie ist sein Input (Konfiguration, Sensoren, Aufgaben)?
- wie kommt dieser Input in das System (per Event oder wird der Input abgeholt)?
- wie ist sein Output (Arm-Motoren, fährt/geht er)?
- wie sieht ein typischer Anwendungsfall aus?

Gruß
Werner

Na dann probiere ich dir mal auf deine Frage zu antworten, damit du mir meine Frage beantworten kannst

- wie ist der Roboter aufgebaut?
Also: Der Roboter hat gewisse Komponenten, die sowohl Hardware (z.B. Greifarm) als auch Software (Selbstlokalisation und Pfadplanung) sein können.

Innerhalb der Verwaltungsklasse sollen alle Komponenten zusammenlaufen (auch wenn das nicht von allen als gute Idee angesehen wird).
Dadurch möchte ich in der Lage sein von der Verwaltungsklasse auf ALLE Methoden des gesamten Programms zugreifen zu können.

- was soll er genau tun; was bedeutet 'autonom agieren'?
Autonom agieren bedeutet, dass der Roboter in der Lage ist ein Problem nicht immer auf die gleiche Art und Weise zu erledigen, sondern auch Abweichungen vom "Plan" verkraften zu können. So sollen z.B. dynamische Hindernisse auf dem Pfad nicht zum Absturz des Programms, sondern zur Neuplanung des Pfades führen.

- wie ist sein Input (Konfiguration, Sensoren, Aufgaben)?
Sowohl Konfigurationsdateien als auch Sonarsensordaten, aber auch eine Sprachsteuerung, die Befehle in einer txt-Datei ablegt, die anschließend ausgeführt werden sollen.

- wie ist sein Output (Arm-Motoren, fährt/geht er)?
Das Abfahren (er fährt) der berechneten Pfade, sowie das Aufnehmen und Transportieren von Gegenständen (alles in einzelnen Klassen realisiert).

- wie sieht ein typischer Anwendungsfall aus?
Der Roboter bekommt den Befehl einen Gegenstand von A nach B zu transportieren.
Bedeutet im Ablauf des Programms:
- Verstehen des Befehls per Spracherkennung
- Abspeichern des verstandenen Befehls in einer txt-Datei
- Auslesen der Befehle aus der txt-Datei (der Umweg über die txt-Datei ist bewusst gewählt)
- Pfadplanung zu Ort A
- Abfahren des Pfades zu Ort A
- Erkennen des Gegenstandes an Ort A
- Aufnehmen des Gegenstandes
- Pfadplanung zu Ort B
- Abfahren des Pfades zu Ort B
- Abladen des Gegenstandes

Wie ihr sehen könnt, da ist einiges zu tun, wobei das nur ein Teil meiner Zielapplikation ist, aber schon ein wichtiger!!

Danke für jede Hilfe

Na dann probiere ich dir mal auf deine Frage zu antworten, damit du mir meine Frage beantworten kannst

Na - dann will ich's mal probieren.

Im Prinzip ist doch das eine Art Transporter. In der realen Welt gibt es da u.a. Schubkarren, LKws und Schiffe. Da beim Software Design die Kunst im Teilen und Herrschen besteht, nehme ich ein Vorbild, wo schon viel Aufgaben verteilt sind; wie auf einem Schiff.

Mal angenommen es gibt einen Kapitän. Der hat einen Greifer (Lademeister), einen Navigator und eine externen Kommandeur. Vom Kommandeur werden die groben Anweisungen gemeldet "Fahre nach A hole Paket P1 bringe nach B". Der Kapitän zerlegt die Anweisungen in kleinere Happen an Navigator und Greifer. An den Navigator "fahre nach A". Der Navigator seinerseits besitzt eine Karte und einen Steuermann. Der Navigator führt an Hand der Karte eine Pfadplanung durch und gibt dem Steuermann einzelne Fahrbefehle: Steuermann drehe um 120Grad volle Kraft voraus fahre 13,5m. Der Steuermann hat einen oder hat Zugriff auf Antrieb und Lenkung und tut was ihm geheißen. Wenn er die Strecke zurückgelegt hat meldet er das 'nach oben'. Der Navigator gibt ihm dann den nächsten Fahrbefehl und wenn der Steuermann fertig beim letzten meldet, so meldet der Navigator "Ziel erreicht" an den Kapitän. Der beauftragt seinen Greifer das Paket P1 zu fassen. Der Greifer wiederum hat einen oder hat Zugriff auf den Roboterarm und tut wie ihm geheißen {hier braucht man noch mehr Input}. Der Greifer meldet ok 'nach oben' und der Kapitän beauftragt wieder den Navigator usw.

Der Navigator hat eine Möglichkeit seine Position_und_Richtung im Raum zu bestimmen {wie kann der Roboter das? wie funktioniert die Selbstlokalisation - bzw. was ist ihr Output?} so kontrolliert er den Weg des Steuermanns. Der Steuermann hat noch ein Sonar mit dem er Hindernisse nach vorne erkennt. Trifft der Roboter während der Fahrt auf ein Hindernis, so hält er an und meldet das 'nach oben'. Der Navigator trägt das Hindernis in seine Karte ein und beauftragt mit den neuen Informationen die Pfadplanung. Mit dem neuen Pfad gibt er wieder Anweisungen an den Steuermann.

So - alle fett gedruckten Hauptwörter sind Klassen. Jedesmal wenn ein 'hat' erscheint ist das eine Aggregation. Also bei A hat B ist B ein Member von A; entweder direkt oder über Pointer und Interface-Klasse wie von viande schon beschrieben. Ein 'hat Zugriff auf' kann ein Zugriff auf eine Ressource sein, die von einem externen (?) System instantiiert wird. Also Sonar, Antrieb, Lenkung und Roboterarm sind sicher nur einmal vorhanden, könnten also auch ein Singleton sein.
Jedes meldet bzw. meldet 'nach oben' ist ein Callback-Aufruf. Die Callback-Funktoren werden dem jeweiligen Server beim Anlegen gleich mitgegeben.
Der Vorteil ist hier, dass die Serverklassen ihren jeweiligen Client gar nicht kennen müssen. Jede Klasse kennt nur wieder die Klassen an deren Objekte es Kommandos abgibt.

Jetzt habe ich noch vergessen zu erwähnen, dass der externe Kommandeur eine Spracherkennung hat. Und die Pfadplanung ist eine Funktion; mit den Parametern Standort, Ziel und Karte und dem Returntyp Pfad (Polygon).

Zur Strukturierung: Wahrscheinlich muss das ganze "Event getrieben" sein, um quasi ein asynchrones Verhalten hinzubekommen. Also z.B. muss ja eine Spracherkennung auch unter dem Fahren möglich sein und nicht erst wenn die komplette Aufgabe erledigt ist (ist das so?). D.h. jeder Methodenaufruf eines Clients an einen Server startet nur die Aktion, kommt aber unmittelbar zurück. Da die Fertigmeldungen immer über Callbacks laufen ist das auch kein Problem. Wenn man das ganze als Singlethread-Applikation auslegt (würde ich erstmal versuchen) so benötigt man eine Hauptschleife, in der auf alle externen Events (Sonar, Endschalter, Sprachsignal) gewartet wird. Und jedes Objekt welches ein Event benötigt muss sich dort mit einem Interface 'anmelden' (siehe Adapter Pattern)

So weit so gut, jetzt ist Dr.Ottel wieder dran seine Meinung zu äußern. Die Bemerkungen in {} sind noch zu klären (s.o.). Insbesondere ist mir nicht klar, wie das Zugreifen passieren soll. Der Roboter muss doch dazu eine bestimmte Position zum Objekt haben und ggf. das Objekt auch "sehen" könne - oder wie funktioniert das?

Ach so und warum

Dr.Ottel schrieb:

Dadurch möchte ich in der Lage sein von der Verwaltungsklasse auf ALLE Methoden des gesamten Programms zugreifen zu können.

ist das so und welche Methoden sind hier genau gemeint?

Und

viande schrieb:

Das mit der Verwaltungklasse ist also vorgegeben, ja?

das hoffe ich doch nicht - wenn ja wieso?

Gruß
Werner

Dein Kommunikationskonzept klingt besser als das mit der zentralen Verwaltungsklasse, denn so kann ich auch Zugriffe über 2 Zeiger und sonstige abstrusen Konstrukte vermeiden.

Zu deinen Fragen:
Roboterarm:
Der ist relativ simple konstruiert und kann sich nur öffnen/schließen und nachdem er z.B. ein Objekt gegriffen hat, sich nach oben bzw. unten bewegen.

Selbstlokalisation:
Der Roboter berechnet anhand der mitgegebenen Karte und den aktuellen Sonarreadings Wahrscheinlichkeiten dafür aus, wo er sich am wahrscheinlichsten befindet und gibt dafür auch die Wahrscheinlichkeit von 0 bis 1 aus.

Sprachsteuerung:
Darum kümmere ich mich gar nicht. Ich bekomme nur die Liste mit den Befehlen, die ich abarbeiten soll.

Nochmals vielen Dank für die Antworten. Sie bringen mich echt weiter!!

.. denn ich gehe mal davon aus, dass du nicht so viel Ahnung von Robotik hast

Nun ich habe schon etwas mit Robotik zu tun; aber meine fahren nicht, können nicht hören und Sonar ist auch nicht.

Dr.Ottel schrieb:

Roboterarm:
Der ist relativ simple konstruiert und kann sich nur öffnen/schließen und nachdem er z.B. ein Objekt gegriffen hat, sich nach oben bzw. unten bewegen.

Ok - für den Greifer sieht das einfach aus. Natürlich muss die Position des Roboters stimmen, sonst greift's nicht.

Dr.Ottel schrieb:

Selbstlokalisation:
Der Roboter berechnet anhand der mitgegebenen Karte und den aktuellen Sonarreadings Wahrscheinlichkeiten dafür aus, wo er sich am wahrscheinlichsten befindet und gibt dafür auch die Wahrscheinlichkeit von 0 bis 1 aus.

Oh oh - das sieht schwierig aus. Naja Du weißt ja wo Du Fragen los werden kannst.

Viel Erfolg
Werner

Ich selbst beschäftige mich momentan auch mit Objektübergreifender Kommunication und bin deswegen sehr neugierig auf richtig gute Lösungsvorschläge. Ich arbeite momentan auch an einer kommunikationsplatform wenn man so will und bin mit der dort verwendeten Lösung überhaupt nicht einverstanden da die Erweiterung sowas von umständlich ist.

Bei mir gibt es sowas wie eine Zentrale Verwaltungsklasse in der alle Kommunikationsvorgänge registriert werden müssen.

Wenn ich jetzt im Übertragenen Sinn einen 6ten Finger an meine Hand implementieren möchte müsste ich praktisch im Gehirn bescheidgeben das der neue Finger bitte in der Lage sein soll mit ihm zu kommunizieren anstatt einfach der Hand mitzuteilen das sie jetzt einen neuen Finger hat und doch bitte dafür sorgen soll das er auch wunderbar funktioniere. Und da jeder Körperteil, Organ sowas wie einen Vorgesetzten hat soll die Information über den Neuen Finger sollange die Hirarchie hochwandern bis der OberSuperLeutnantGeneral mitbekommt das er jetzt nen neuen Sklaven hat. (Den interessiert es recht wenig da er ja schon weiss wie so ein Finger funktioniert, er freut sich nur über ein neues Feature.)

Wenn wir uns das menschliche Gehirn mal (vereinfacht als Ganzes) denken dann fällt auf das es ansich nichts selbst kann, aber es kann was die Summe der andern Körperteile kann. Ich glaube das ist so deine Idee. Einen Punkt von wo aus man die "Kontrolle" hat.