Beiträge von copter

also, hab mich schlau gemacht (sps-messe in nürnberg) :

objektorientierte programmierkonzepte in der sps (=anlagen) - technik arbeiten mit globalen variablen, entsprechend dem "prozessabbild".
-> alle prozesswichtigen werte werden im hauptprogramm (hier main) als variable definiert. alle objekte können damit (und so auch "darüber") kommunizieren.
(wird als übersichtlicher und weniger syntaxintensiv beschrieben, ist auch kompatibler zu "alten" konzepten)

ich denke, diese argumente treffen auch für so kleine controller-applikationen wie meinen quadrocopter zu. alle prozessvariablen werden in main deklariert, und entweder als parameter für methoden benutzt oder (auch bei mehr als einem rückgabewert) direkt um den methodenaufruf rum übergeben. wird sehr übersichtlich !

so etwa :

nickregler.acc = sensor_4; //variable in attribut (eingänge, könnten auch parameter sein..)
nickregler.gyro = sensor_7;
nickregler.stabilisieren(); //methode
nickkorrektur = nickregler.stellwert //attribut in variable (ausgänge, bei nur einem ging's auch als rückgabewert)

die attribute sind, soweit sie kommunizieren müssen, public. ist ne m2m-kommunikation, die bei einem fehler (sensorausfall) sowieso das ende bedeutet. also, so what, private bringt nix.

(weiter : konstruktor wird im normalfall nicht benutzt (=default), außer wenn anfangswerte (höhe=0 oder ähnliches...) zu setzen sind)

das gehirn ist verteilt :

sensorik misst werte, prüft diese auf plausibilität, fusioniert manche, rechnet mit wahrscheinlichkeiten, filtert.
regler machen aus soll- und ist-werten neue steuerwerte, passen sich an situationen an, reagieren auf ereignisse.
antrieb gewichtet die einflüsse, vergibt prioritäten, verteilt steueraktionen angepasst an verschiedene motoren

..usw.

natürlich gibt es auch unterlagerte klassen (z.b. die reine motoransteuerung oder das lesen eines a/d-wanlders oder so...),
die kann man ohne strukturschwäche auch in anderen objekten referenzieren.

dazu kommen ein paar aufgaben, die sich nur als interruptroutinen lösen lassen, da versagt das oo-konzept völlig.

-------------------

ich denke es wird auf eine lösung rauslaufen, die sich an das sps-konzept des "prozessabbilds" anlehnt.
alle prozessrelevanten werte werden als variablen in main angelegt.

(trotzdem arbeite ich das pointer/referenzen-konzept mal aus)

ich will ja nicht lästig sein, aber vielleicht habt ihr ja auch spaß am gedankenaustausch ..

übergeordnete module .. der controller ... eben nicht !

in modern strukturierten modularen system gibt es eben keinen zentralen "master" oder so, sondern eine einfache kommunikation zwischen hierarchisch gleichwertigen modulen ("peer-to-peer" sozusagen).
natürlich sind dazu an jedem modul saubere schnittstellen zu definieren, aber eben ... modulkommunikation untereinander (!) -> was hier bedeuten würde, objekte müßten gegenseitig ihre attribute (oder, mal phantasiert : "spezielle kommunikationsattribute") zugreifen können. gerne über get/set oder so.

ich les' mal, wie das die objektorientierte sps-technik macht ...

na ja, die grundlagen der objektorientierung hab ich glaub ich verstanden. pointer machen mir n paar probleme, in den "alten sprachen" (ich hab mal mit fortran angefangen vor 100jahren war sowas unüblich ..das krieg ich aber gebacken ... ich hadere eher mit den grundlagen.

als programmierkonzept ist das in meinen augen ein modularisierungswerkzeug. besser strukturiert als klassisch functions, procedures und all das. kapselung ist z.b. auch nur ein aspekt der modularisierung ...
folge von modularisierung ist in jeder technischen struktur dann kommunkationsbedarf. in module gegliederte funktionalitäten ziehen das unweigerlich nach sich.
aber : anders als in anderen modularisierungskonzepten fehlt hier ein sauberes konzept, die module (=objekte) dann auch kommunizieren zu lassen...

in meinen augen fehlt eine, übersichtliche, klar strukturierte funktionalität, um ein objekt mit einem anderen kommunizieren zu lassen.
(ich frage mich, wie das in objektorientierten konzepten der industrieanlagenprogrammierung läuft, da ist die modularisierung ja das kerngeschäft.)

... aber das werdet ihr hier als informatik-freaks sicher anders sehen. (...eben gar nicht als problem, stimmts ?)

erstmal : vielen dank für deine hilfe (deine zeit).
die syntax krieg ich auf die reihe, muß halt lesen ...

wenn ichs richtig verstehe (das ist mir das wesentlichste) :

ein pointer zeigert auf einen speicherplatz. da wird ein wert abgelegt, und kann dann in jedem beliebigen objekt wieder als pointer zugegriffen werden. der driekte zugriff auf die speicherzelle ohne variablen(-attribut)definition "umgeht" sozusagen das problem, daß die attribute nicht untereinander von den objekten zugegriffen werden können.

ich melde mich, wenn ichs syntaxtechnisch am schnürchen und getestet habe.

wie gesagt, sind immer mehrere objekte einer klasse. was bringt dann das singleton ?

die objekte werden alle in der main (übrigens auf einem atmega128) angelegt. nochmal (verzeiht die anfängerfrage !) ... was ist eine "referenz", die ich in der init-methode anlegen kann. kann ich ein (symbloisches) code-beispiel haben ?

beispiel : eine klasse macht lageregler , eine andere klasse steuert motoren.

im programm : das motoren-objekt kriegt vom lageregler-objekt (davon gibts dann mehrere, für jede raumachse einen) stellwerte für die drehzahl.

"muß es natürlich referenzen geben" .. was heißt das in c++ ??

"singleton-pattern" ist wenn ich nicht irre die referenzierung in genau einem objekt. hab ich nicht, das sind immer mehrere objekte einer klasse.

ich programmiere einen quadrocopter, in c++, objektorientiert.
oo verstehe ich hier als technik der modularisierung, andere werkzeuge (vererbung etc. benutze (brauche) ich nicht).
nun taucht im programm (main, aufgerufen von 200hz-timerinterrupt) folgendes problem auf :
die objekte müssen untereinander kommunizieren.

symbolisch gesagt :

klassen : a und b, methoden : a.methode und b.methode, attribute (public) : a.attribut und b.attribut
im programm dann die objekte : a_objekt und b_objekt (davon gibts rund 20)

frage : wie kann a_objekt.methode auf b_objekt.attribut zugreifen ??

- attribute als objekte, also "ineinander referenzieren" wird bei der vielzahl sehr unübersichtlich
- lauter variablen im main ... das kanns nicht sein
- ?????