Finde ich auch sinnvoller - hab nur das Abgebildet was er schon hatte.
Vielleicht will er ja auch erst mal "einfach und klein" anfangen.

Und auch wenn ich c/cpp bevorzuge würde ich nicht "richtige Sprache" als Attribut zur Abgrenzung hernehmen - das was er da nehmen will ist genauso eine
Und jeder soll nehmen was er kann (muss natürlich zum Projekt passen).
Würde er C/Cpp nehmen könnten ihm aber eventuell mehr Leute helfen können als mit Luna-AVR - aber nützt ihm ja nix wenn er dann so gar nicht mit klar kommt.

the-fallen hat geschrieben:Würde er C/Cpp nehmen könnten ihm aber eventuell mehr Leute helfen können als mit Luna-AVR - aber nützt ihm ja nix wenn er dann so gar nicht mit klar kommt.

Das meinte ich im Prinzip

was meint "er" dazu ?

first of all : ich suche seit geraumer zeit in der copter-szene nach ansätzen, das mit modernen programmiertechniken anzugehen. find aber nix, alle programmieren wie wild prozedural.
kann ich ncht brauchen, auch wenns performance-mäßig natürlich vorteile hat. also : klassendiagramm !

ob das dann in c++ gecodet wird, oder in luna, ist unwichtig. wenn man dem mainstream folgen mag : natürlich c, keine frage. hier bei mir wirds vermutlich nach der "finalen" modellierung
im klassendiagramm beide lösungen geben, c++ (aber zu fuß, nicht aus dem codegenerator von sisy) und luna.

für den tip mit der einschränkung durch 4 motoren bin ich dankbar, ich hab halt mit meinem "spaßvogel" (http://www.youtube.com/watch?v=7n_0k4MI8j4) nur sehr beschränkten überblick. ich dachte auch zunächst, als oberste funktion einfach die lage im raum anzusetzen, mit geschwindigkeit und beschleunigung, und darunter alles abzuleiten. damit bin ich aber, wahrscheinlich weil mir hier die erfahrung in oo fehlt, leider gescheitert.

also : sollwerte sind winkel in kartesischen copter-achsen, wie die motorenmischer daraus drehzahlen rechnen, hängt von der geometrie ab, oder ?

dollreiner hat geschrieben:first of all : ich suche seit geraumer zeit in der copter-szene nach ansätzen, das mit modernen programmiertechniken anzugehen. find aber nix, alle programmieren wie wild prozedural.

Funktioniert halt siehe Wii-Copter.

Aber, ich kann Dich verstehen. Ich bin, wie fast jeder Programmierer, recht faul, also bevorzuge ich lesbaren Code, ohne auf 10 Zeilen Code 20 Zeilen Kommentare zu brauchen.

Ich finds auch völlig ok wenn du erst mal "nur" mit 4 Motoren in +Kombination anfängst. Da hast du so schon genug zu tun und erweitern kann man das dann später ja.

Besser so als wenn dir aufgrund der Komplexität die Lust vergeht.

the-fallen hat geschrieben:Ich finds auch völlig ok wenn du erst mal "nur" mit 4 Motoren in +Kombination anfängst. Da hast du so schon genug zu tun und erweitern kann man das dann später ja.

Aber wenn man das von Anfang an ins Design packt, kann es jeder später nach Gusto erweitern.
So viel mehr Aufwand ist das nicht.

Mehr sorgen macht mir dann eher das GUI. Multi-Wii ist ne Katastrophe.

Da könnte ja z. B. auf das mavlink-Protokoll zurückgreifen. Ist ja nicht so das es keine Copter mit offenem code gibt die keine ansehnliche GUI haben.

verzeiht meine ahnungslosigkeit. was für ein gui ??
weder die steuerung noch die telemetrie sind bei mir graphisch (telemetrie schaut aus wie ein sechskanal-oszi, ist unter vb .net).
und selber ein display (hud oder so) in das osd mit reinzuschreiben hab ich nicht (mehr) vor.

Naja ich glaube die Beiden haben so eine vollwertige Steuerung mit Einstell-Oberfläche am PC im Hinterkopf.
Ich vermute mal, an so was Großes hattest du selber gar nicht gedacht, oder?

Mach einfach erst mal das was du vorgehabt hattest und dir zutraust - dabei werden wir dir auch so gut wir können helfen.

mein ziel :

kein kunstflieger ! ne stabile plattform für kamera und gemütliches steuern.
autonomer quadro, gps für stabilen ort und rth, höhe mit druck, acc und gps-höhe (fusion). gier mit kompass.
steuerung über rs232-funk, joystick am laptop. kamerabild mit osd am laptop (latenz bei gps-unterstützung unkritisch)

wichtiger als das erreichen des ziels :

austesten der möglichkeiten objektorientierter entwicklung (sprache egal).
vergleich mit bestehender lösung (prozedural in luna, kann alles bis auf gps).

.. und da stottere ich jetzt rum. prozedural ging das schnell, ist schon früh gefolgen, aber ein wirklich sauberes
klassendiagramm ..? ich schlag jetzt mal ein minimalmodell vor. die umschaltung der verschiedenen flugmodi
mit gps und weiteren achsreglern (höhe, gier) wäre nächster schritt : http://www.reinerdoll.de/my3.jpg

denkt ihr, daß wenigstens das so durchgehen kann ?

GUI := Graphical User interface - Ist das gegenstück zum CLI : Comand Line Interface.
Alos alles wo man Irgendwas anderes als Text lesen und eintippen kann ist ein GUI.

das ist mir schon klar, aber wozu man das im copterzusammenhang braucht, erschließt sich mir nicht.
oder reden wir von einem selbstgeschriebenen osd ?

dollreiner hat geschrieben: wozu man das im copterzusammenhang braucht, erschließt sich mir nicht.

Na,wie willst du z.B. Irgendwelche Werte eingeben? Alles über die Komandozeile? Klar, geht das, aber das kann man heute kaum noch jemandem an die Hand geben.
Schau dir z.B. mal beim Arducopter um. Da wird alles über den Mission Planer gemacht. vom ersten Aufspielen der Firmware (Selbst ob es sich um ein Auto ein Flugzeug oder einen Copter und wenn Copter um welche Bauform ... kann man alls über GUI eingestellt) über einstellen der Regelparameter bis hin zum Waypointing.

Also das Diagramm ist leider nicht richtig
Folgendes ist mir aufgefallen:

Die Rauten gehören an das benutztende Objekt (also zeigt ausgehend vom zu benutzenden Objekt zum Benutzer).
Dann ist die i2c-Adresse kein Byte sondern ein Byte-Array.

Weiterhin hast du in deinem Hauptprogramm mehrmals den Datentyp "sensorik", für jede Achse eine Instanz- allerdings weiß ich nicht ob du das wirklich so machen willst, denn innerhalb der Klasse sensorik hast du ja die Werte aller Achsen. Wäre irgendwie doppelt gemoppelt.

Währe ich Lehrer würde ich die fehlenden Marker für public/private/protected/etc bemängeln

Aber lass dich nicht entmutigen, je mehr Gedanken du dir jetzt machst um so durchdachter ist nachher das Ergebnis.

zitat frankfly : Schau dir z.B. mal beim Arducopter um.

ok, jetzt versteh ich was du meinst.
für meine zielfunktion braucht zunächst kein grafikdisplay. kamera und osd sind fertig vom hobbykönig, mein gps soll nur a) bei loslassen der knüppel den ort halten oder b) bei steuer- oder orientierungsausfall rth fliegen. für beides muß ich keine waypoints eingeben. meine telemetrie soll nur meßwerte runterschicken, damit ich die sensorik beobachten kann. und das stelle ich auf meinem "vb-oszi" dar.
zur orientierung baue nur ein einfaches osd (vom hobbyking) ein. damit fliegen dann 2 gps mit, macht aber auch nix ...