Sender der nächsten Generation

[lxh]

Wenn ich mir anschaue, was Modellflieger alles zu Geld machen wollen, da werden "leicht beschädigte Tragflächen, Kabinenhauben, einzelne Leitwerke" von Absturzflugzeugen zum KAUF angeboten, dann funktioniert das nach meiner Meinung eben nicht.

Hallo Klaus,

wenn ich mir aber ansehe mit welcher Geduld sich Kollegen der Programmierprobleme anderer annehmen, wird offensichtlich dass kein kommerzieller Hintergedanke, sondern Hilfsbereitschaft der Antrieb ist. Du, ich, und jeder der kann hilft gerne wenn sich zeigt, dass andere nicht weiter kommen. Ich finde wie gesagt, dass diese einzelnen Bemühungen dauerhafte Lösungen hervorbringen sollten. Mehr nicht ...

Gruß, Alex

 

[KO]

Hallo Klaus,

wenn ich mir aber ansehe mit welcher Geduld sich Kollegen der Programmierprobleme anderer annehmen, wird offensichtlich dass kein kommerzieller Hintergedanke, sondern Hilfsbereitschaft der Antrieb ist. Du, ich, und jeder der kann hilft gerne wenn sich zeigt, dass andere nicht weiter kommen. Ich finde wie gesagt, dass diese einzelnen Bemühungen dauerhafte Lösungen hervorbringen sollten. Mehr nicht ...

Gruß, Alex

100%ige Zustimmung von mir,

Klaus

 

[Pike]

Aber mal eine ganz andere Idee, wie wäre es denn mal mit einer grafischen Programmierung, in der die Mischer usw. als Blöcke dargestellt werden, und wo man die Funktion als Blockschaltbild eingeben kann. Die Mischer- und Funktionsblöcke kann man dann entsprechend noch einstellen oder mit weiteren Funktionen füllen?

 

[Prof. Dr. YoMan]

Siehe:

http://www.rc-soar.com/multiplex/mpxevo/markdrela/mdrela.htm

Schön graphisch verständlich.

Unten auch der schöne Vergleich wie krude das klassisch gelöst wird.

 

[MarkusN]

Unten auch der schöne Vergleich wie krude das klassisch gelöst wird.

"Aber die ganzen vordefinierten Mischer machen doch das Leben so einfach!"

Yeah, right.

 

[Peter Feix]

@Pike und dann kann mehr als 60 % der Anwender das Ding nicht programmieren!
Alles schon erlebt!

 

[Pike]

Na und?

Na und?

@Pike und dann kann mehr als 60 % der Anwender das Ding nicht programmieren!
Alles schon erlebt!

Na und? Wenn es mir leichter fällt, dann würde mir das schon reichen! Ich sage das nur, weil mir sowieso immer wieder von anderen Piloten gesagt wird, dass die von mir verwendeten Sender (FC28 und FX30) schlecht wären, weil man sie nicht programmieren könnte. Ich kann aber und ich kann das schnell und effektiv. Wenn du es den meisten Leuten recht machen wolltest, dann müsstest du auf alle Sender eine Graupnersoftware aufspielen und die am besten nie mehr ändern. Das ist aber ganz und gar nicht das, was ich mir für einen Sender der Zukunft vorstelle.

tschüß,
Pike

 

[Snoopy]

Meine Meinung zur Fernsteuerung der Zukunft:

Der Sender muss bald nix mehr können. Zwei vernünftige Knüppelaggregate und ein paar Schalter sind drin. Die Logik sitzt im Empfänger.

Das machen die modernen Helis doch schon vor. Bei den 3-Achs Stabilisierungssystemen braucht man nur noch einen simplen 5-Kanal Sender, der keinen Mischer mehr haben muss. Der Rest wird an Bord gemischt und eingestellt.

Das macht es auch viel leichter mit verschiedenen Sendern das gleiche Modell steuern zu können.

Eine bidirektionale Kommunikation mit Telemetrie wäre Pflicht für mich. Force-Feedback kommt dann bestimmt auch irgendwann noch...

 

[lxh]

@Pike: Gute Idee, wie wäre es dann mit einem GUI Constructor für den PC?

@Peter Feix: Guter Einwand, sollte aber natürlich nur optional sein.

@Snoopy: Sehr interessanter Ansatz, könnte aber dazu führen für jeden einzelnen "Empfänger der Zukunft" ein Vermögen zahlen zu müssen. Wenns der Sender schon kann, bleiben diverse Logiken unter den Usern tauschbar.

 

[lxh]

@Pike:

Der GUI Constructor könnte für neu entwickelte Funktionen in etwa so aussehen ...

Was hältst du davon?

Gruß, Alex

 

[sidigonzales]

@Snoopy: Sehr interessanter Ansatz, könnte aber dazu führen für jeden einzelnen "Empfänger der Zukunft" ein Vermögen zahlen zu müssen. Wenns der Sender schon kann, bleiben diverse Logiken unter den Usern tauschbar.

und warum soll das nicht austauschbar sein wenn man die Logik im Empfänger hat?
Was das kostet kann man schön an den Jeti REX JBC sehen. Da wird mal vorexerziert wie es geht.
Mit LowTec ATMega.

Und nur mal so als Einwand zu den Mixerorgien. Wenn ich eine Handvoll Eingangsgrössen habe die ich auf eine Handvoll Ausgangsgrössen mit Abhängigkeiten abbilden will werde ich wohl nicht umhin kommen komplexe Strukturen zu erzeugen und das ist völlig unabhängig davon ob ich vordefinierte oder freie selbst definierbare Mixer verwende.
Entweder stelle ich einen wohldefinierten Mixersatz zur Verfügung oder ich kreiere eine komplexe Programmierumgebung mit allen Unwägbarkeiten.
Letztlich führt ihr gerade die Diskussion weiter was besser ist. RISC oder CISC.

Man kann sich Konzepte auch so lange schön reden bis man selber daran glaubt.

sanfte Grüße

 

[lxh]

Entweder stelle ich einen wohldefinierten Mixersatz zur Verfügung oder ich kreiere eine komplexe Programmierumgebung mit allen Unwägbarkeiten.

Das eine schließt doch das andere nicht zwangsläufig aus. Wie gesagt, die einen bekommen auf WUNSCH neue und individuell anpassbare Mixersätze, die anderen können diese weiterentwickeln, verfeinern oder wiederum neue entwickeln.

Gruß

 

[KO]

@Snoopy: Sehr interessanter Ansatz, könnte aber dazu führen für jeden einzelnen "Empfänger der Zukunft" ein Vermögen zahlen zu müssen. Wenns der Sender schon kann, bleiben diverse Logiken unter den Usern tauschbar.

Hi,

das gibt es schon als Onboardsystem, allerdings nicht als Empfänger, aber als Stabilisierungssystem für Helis. Vstabi läßt sich konfigurieren und dann am PC abspeichern und als Datei weitergeben, oder auf einen anderen Heli übertragen ( hab beides schon genützt ). Funktioniert bestens, ist sehr beliebt bei den Vstabi-usern, aber sehr umstritten bei den Gegnern (weil so aufwändig und kompliziert zu programmieren?)

Grüße Klaus

 

[Pike]

@lhx

Nö, eigentlich gefällt mir die Ausführung aus Prof.Yo.Mans Link noch besser. Wenn du mal mit Matlab Simulink oder ähnlichem gearbeitet oder hast, oder sowas gesehen hast, so was meine ich. Dann hat man zum Beispiel einen Block, der Heißt Knüppel. Dem Sage ich, du heißt Querruder, und nimmst J1. Und dann kommt da ein Ausgang raus, den ich durch einen oder mehrere oder keinen Trimmerblock oder ATV-Block oder Kennlinie, oder addierer oder Multipizierer oder sonst einen vorgefertigten Mischer ziehen kann. Und am Ende Gibt es einen Block der zum Beispiel Kanal oder Servo heißt, und der zu einem Emprängerausgang gehört. Neben den Blöcken für vorgefertigte Mischer könnte es noch Blöcke für Differenzierer, Filter, Verzögerungsglieder, Integrierer, Timer, Schalter, Logik und so weiter geben. Man holt einen Block aus einer Library und verbindet die Ein und Ausgänge. Grafisch sieht man sofort was passiert, und man kann jeweils nur so viele Blöcke aus der Library holen, wie in der Software vorhanden sind - so stelle ich mir das für zukünftige Sender vor!

 

[lxh]

Ja Pike, das wäre ja auch gut so. Meine Grafik soll veranschaulichen, wie man danach aus einer komplexen Funktion ein Grafisches User Interface (GUI) zur einfachen Anwendung erstellen könnte. Das ganze macht ja nur dann wirklich Sinn, wenn beide - die Coder und die Anwender - ihren Vorteil daraus ziehen können. Die Coder kriegen noch mehr Kontrolle und die Anwender eine höchst einfache Eingabemaske für diese neuen Funktionen.

 

[lxh]

PS: Du darfst dabei bitte nicht vergessen, dass nicht jeder mit sowas umgehen kann. Wenn du DAS dem Durchschnittsanwender aufbrummst, wäre das wie wenns auf deren Uhr plötzlich 12:63 schlägt. Man MUSS dabei auch in die andere Richtung weiterdenken ...

 

[Gast_4631]

In den größeren Sendern, also mc24, mc22, fc28 und die Klasse sind schon weit leistungsfähigere Controller drin als Atmel 8 Bitter

Welche? Diese Kisten sind immerhin schon recht alt...

 

[Gast_4631]

Aber mal eine ganz andere Idee, wie wäre es denn mal mit einer grafischen Programmierung, in der die Mischer usw. als Blöcke dargestellt werden, und wo man die Funktion als Blockschaltbild eingeben kann. Die Mischer- und Funktionsblöcke kann man dann entsprechend noch einstellen oder mit weiteren Funktionen füllen?

Logisch habe ich das auch so aufgebaut und fuer eine Desktop-Software haette ich das auch gerne - aber auf dem Anlagendisplay ist dafuer schlicht kein Platz :-(

 

[lxh]

Logisch habe ich das auch so aufgebaut und fuer eine Desktop-Software haette ich das auch gerne - aber auf dem Anlagendisplay ist dafuer schlicht kein Platz :-(

Hallo Peter,

wenn man diese Blöcke - so wie Pike sie nennt - zusammenfasst und jeweils wieder einzoomt bzw. öffnet, könnte sich das u.U. sogar ausgehen - als "wachsende Menueführung" sozusagen. Diese Zusammenfassungen der Einzelteile des Datenflussplans, könnten wiederum Namen bekommen bzw. Subfunktionen werden. Ist das deiner Meinung nach zu weit her geholt?

Gruß, Alex

 

[lxh]

Hi Pike,

grundsätzlich ist eine Darstellung in Form eines Datenflussplans ja eine ganz gute Idee. Ich arbeite seit Jahren mit etwas ähnlichem aber die Praxis hat gezeigt, dass es der Übersicht nicht immer förderlich ist. Hier mal ein Antibeispiel aus einem anderen Bereich, das trotz Kürzung durch Skriptblöcke immer noch ein "Wirrwarr" bleibt. Die Darstellung auf einem Senderdisplay wäre ein unzumutbarer Alptraum.

Variablen in Form von virtuellen Gebern wären meiner Meinung nach der smartere Weg, trotzdem gefällt mir die Vorstellung einer vereinfacht grafisch-logischen Datenfluss-Darstellung als Menuestruktur. Die Frage ist nur: Wie kann man es tatsächlich vereinfachen? Hast du eine Idee?

Gruß, Alex