Lieber Besucher, herzlich willkommen bei: RCLine Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Freitag, 23. Juli 2010, 23:58

Neue Idee, oder?

Hi,

heute auf der Arbeit hatte ich irgendwie etwas Zeit zum überlegen. Dabei habe ich mir folgendes Konzept für den "ultimativen RC-Sender" überlegt.

Wenn man sich die Preise für die "großen" RC-Sender anschaut, dann wird einem ja schlecht. Und das für ein wenig Rechenkapazität die von jedem billigen Netbook um Größenordnungen getoppt wird. Also warum nicht gleich ein solches Netbook als Basis für eine Selbstbau-Anlage nehmen? Dann hätte man - im Vergleich zu aktuellen Kaufanlagen - praktisch unbegrenzt Kapazität für "Modellspeicher" und eine komplexe Programmierung. Und ganz nebenbei noch ein Display mit dem man die Programmierung WIRKLICH benutzerfreundlich machen könnte. Auch die Anzeige und Auswertung von Telemetriedaten wäre dann wirklich kein Problem. Selbst Sprachausgabe über Ohrhörer (gerne auch Bluetooth) liefert ein solches System doch locker nebenbei.

Was also bräuchte man?

1. Netbook. Fabrikat und Leistungsfähigkeit ziemlich beliebig. Lange Akkulaufzeit haben die Dinger eh. Oder man versorgt sie über die Netzbuchse aus einem externen Akku.

2. Funkmodul mit PC-Anbindung. Sinnvollerweise in beide Richtungen, also Senden und Empfangen, damit man die Telemetriedaten auch zum PC zurück bekommt. Im Prinzip würde sich auch sowas wie Jeti eignen, wenn man über den Audio-Ausgang ein entsprechendes PPM-Signal generiert. Für die Telemetrie müsste man sich dann halt was überlegen um mit dem PC eine "Jeti-Box" zu emulieren.

3. Eingabegeräte. Knüppel müssen schon sein. Analoge Knüppel sind aber irgendwie doof. Wenn ich mir alleine den Linearitätsfehler bei industriell hergestellten Kreuzknüppeln anschaue wird mir ziemlich schlecht. Die sinnvoll erreichbare Auflösung erscheint mir auch ziemlich mickrig. Auch wenn einige Hersteller von RC-Sendern mit 16 Bit = 65536 Schritten werben: Wo sollen die herkommen, wenn man Potis in den Knüppeln verwendet? Gibt es "digitale" Kreuzknüppel z.B. mit inkrementellen Drehgebern? Und kann man sowas bezahlen?

4. Software. Klar. Das Wichtigste. Wobei man in diesem Fall ja ruhig klotzen statt kleckern kann. Alles ganz einfach und direkt am Netbook am Besten grafisch zu "programmieren". Keinerlei "Vorbelegung" der Kanäle. Stattdessen werden die Bedienelemente als "Geber" definiert und bekommen jeweils einen Namen (Knüppel links horizontal/vertikal, Trimmer links vertikal/horizontal, Knüppel rechts horizontal/vertikal, Schalter links vorne etc.). Man definiert nun eine beliebige Steuercharakteristik für die Bedienelemente, also Werte für Vollausschlag links/rechts und Neutralstellung. Bei Schaltern und Reglern dito. Diese Werte dienen nun als "Eingang" für die Mischer. Vordefinierte Mischer werden von der Software als "Black-Box" zur Verfügung gestellt um "übliche" Aufgaben (Taumelscheibe, 2-4-6-8-Klappenflügel, V-Leitwerk usw.) einfach programmieren zu können. Ansonsten gibt es eine (nahezu) beliebige Zahl von freien Mischern mit denen man herumspielen kann.
Zusätzlich stelle ich mir beliebig viele Flugphasen vor die man über die Geber/Schalter auswählen kann. Wahlweise sollte man die Option haben die gewählte Flugphase über z.B. einen Knüppeltaster bestätigen zu müssen, damit es nicht so leicht zu versehentlichen Umschaltungen kommt. Beim Betätigen des Flugphasenschalters könnte dann eine Sprachansage die gewählte Flugphase nennen und mit Druck auf den Knüppeltaster wird sie dann aktiv. Wobei jede Flugphase einen eingebauten Sequenzer auslöst (der auch unabhängig genutzt werden kann). Mit diesem Sequenzer kann man den zeitlichen Ablauf der Änderungen die durch diese Flugphase bewirkt werden steuern. Also z.B. so:

1. Flugphase Stand
Höhenruder "hängt" runter (wie bei manchen großen Fliegern auch). Motor ausgeschaltet. Fahrwerk ausgefahren. Fahrwerksbremse aktiv. Beleuchtung aus.

2. Flugphase Start
Alle Ruder neutral. Nach 2 Sekunden gehen die Navigationslichter an. Nach weiteren 2 Sekunden die Rollscheinwerfer. Weitere 2 Sekunden später wird das Gasknüppel aktiv. Im unteren Drittel agiert er zusätzlich als Radbremse.

3. Flugphase Normal
Alle Ruder neutral. Gas auf Gasknüppel. Alle Lampen an. Umschaltzeit 0 Sekunden. Nach 2 Sekunden Fahrwerk einfahren. Nach weiteren 2 Sekunden Wölbklappen innerhalb von 4 Sekunden auf normal fahren.

4. Flugphase Landung
Umschaltung Wölbklappen auf Landestellung innerhalb von 4 Sekunden. Nach 5 Sekunden Fahrwerk ausfahren. Anschließend Landescheinwerfer einschalten.
Oder beim Segler z.B. Butterfly auf den Gasknüppel legen.

Und so weiter. Solche Sequenzer lassen sich grafisch sehr einfach darstellen und programmieren und man könnte eine Menge Sachen damit machen. Zusätzlich sollte es noch einen Notknopf geben der sämtliche gerade "laufenden" Sequenzer auf die Endposition setzt (falls man beim Landeanflug merkt, dass man vergessen hat auf die Landephase zu schalten und das Fahrwerk ist noch drin...). Grundsätzlich könnten die Flugphasen den kompletten Sender "umprogrammieren" und eine der jeweiligen Flugphase angepasste "Benutzeroberfläche" präsentieren. So käme man für die meisten Fälle sogar mit sehr wenigen Schaltern aus, die dann halt je nach Flugphase unterschiedliche Dinge machen (Ein Schalter könnte z.B. beim Start die Schleppkupplung eines Seglers bedienen und bei der Landung die Radbremse - je nach Flugphase halt).

Grafische Mischer (nicht 5- oder 7-Punkt-Mischerkurven, sondern beliebig viele Punkte...) wären auch kein Problem.

Servolaufzeiten und -charakteristika sollten kein Problem sein. Auch nicht, wenn man (z.B. Fahrwerk) zunächst schnelle Bewegungen haben möchte die gegen Ende langsamer werden. Telemetrie könnte einfachst mit Sprachausgabe unterstützt werden. Die Anzahl der ansteuerbaren Kanäle hinge nur von der verwendeten Sendetechnologie ab. Verwendet man z.B. ein Jeti-Modul, so wären 16 Kanäle kein Problem. Verwendet man eine digitale Anbindung an das Sendemodul, so ließen sich auch noch Unmengen an Schaltkanälen übertragen (was ja über PPM-Kopplung nur begrenzt möglich ist).

Das Ganze sollte prinzipiell schon mit einem Auslaufmodell-Billigstnetbook für 100,- oder 150,- Euro machbar sein. Dazu dann ein 2,4 GHz-Modul (für die einfache Ausführung) um die 100,- €. Und ein paar Bedienelemente (da kann man beliebig viel Geld ausgeben). Könnte man für erste Versuche auch durch einen Simulatorsender ersetzen. Die Sprachmeldungen (Flugphasen, Telemetrie-Warnungen, Sender-Akkuwarnung etc.) könnte man sogar per Mikro selbst einspielen. Die Flexibilität eines solchen Systems würde alles schlagen, was es auf dem Markt derzeit gibt.

Man müsste natürlich alles in ein sinnvolles Gehäuse packen. Ideal wäre es noch, wenn man Tastatur und Display trennen könnte (ist halt etwas Bastelarbeit). Die Tastatur verschwände dann "unten" im Sender in einer Schublade, wenn sie nicht benötigt wird - der Bildschirm sitzt oben und bleibt dauernd sichtbar. GPS-Telemetriedaten ließen sich quasi "live" in der Karte darstellen (Modellortung nach Außenlandung...). Man bräuchte nur noch einen UMTS-Stick.

Was haltet ihr von dem Konzept? Bei Verwendung "fertiger" Module müsste das Ganze doch sogar völlig legal betreibbar sein, oder?

Ciao, Udo

2

Samstag, 24. Juli 2010, 14:00

Nur dass es die Rechenleistung des Atoms garnicht braucht für eine Fernsteuerung. Ansonsten kommt die RCOS denke ich mal schon einigermaßen ran en deine Vorstellung, die Programmierung das Modells am PC (oder am Netbook zum immerdabeihaben) ist kein Problem, und Knüppelaggregate mit Hallsensoren gibts auch, guck mal in den Geber Thread.

Die Flugphasen sind ja auch kein Problem und ich glaube die graphischen Mischer gibts auch schon, zumindest mit recht vielen Punkten.

Ich glaube ich muss meine mal endlich fertig bauen :D

Ein Problem könnte noch die Echtzeitanbindung sein da Netbooks nur USB Anschlüsse haben, d. h. man müsste einen finden mit echtem Expresscard Slot (die sind auch oft nur mit USB angebunden).
[SIZE=2]Mit freundlichen Fliegergrüßen,Björn :w[/SIZE]

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »MiniMagister« (24. Juli 2010, 14:02)


3

Samstag, 24. Juli 2010, 16:04

Naja. Die Rechenleistung braucht man sicherlich nicht, könnte sie aber durchaus gewinnbringend einsetzen. Beispielsweise zur Live-Übertragung von Video aus dem Flieger mit Anzeige auf dem DIsplay. Nebenbei MP3s hören wäre auch manchmal ganz nett beim Segelfliegen ;-) Mit Priorisierung der Sprachansagen der Fernsteuerung.
Entscheidend ist aber meiner Meinung nach, dass man für relativ wenig Geld eine Menge Hardware bekommt, wenn man ein billiges Netbook kauft.
Und was spricht gegen USB? Echtzeitfähigkeit ist "relativ". Wie groß sind denn die Verzögerungen, die man bei USB erwarten kann? Im Bereich einiger Millisekunden merkt das kein Mensch.

Ciao, Udo

4

Samstag, 24. Juli 2010, 18:02

Zitat

Original von ubit
Und was spricht gegen USB? Echtzeitfähigkeit ist "relativ". Wie groß sind denn die Verzögerungen, die man bei USB erwarten kann? Im Bereich einiger Millisekunden merkt das kein Mensch.

Ciao, Udo


Immerhin sind die möglichen Verzögerungen groß genug dass man USB Schnittstellen nicht für die direkte Ansteuerung von CNC Fräsen nutzen kann, die Bahnsteuerung muss dann ausgelagert werden. ich glaube das problem bei USB ist das Cueing der Befehle, wenns dann ins Stocken kommt wird halt der nächste statt des aktuellen Befehls gesendet. Sprachausgabe gibts auch schon (Ich weiss garnicht ob ich das in nem Jeti Thread oder hier gelesen hab, MP3 Player kommen auch ohne großen Prozessor aus ;)
Die Videoübertragung auch, ich sehe es auch nicht als besonders glücklich an wenn dann plötzlich sämtliche Prozesse über einen Prozessor laufen, nicht dass dann wenn Video oder Musik hängen bleiben das Modell abstürzt.

Ein Netbook an die RCOS oder Jeti anzubinden um Telemetriedaten anzuzeigen oder es allgemein als Frontend zu verwenden ist ja gar nicht so schwierig.
[SIZE=2]Mit freundlichen Fliegergrüßen,Björn :w[/SIZE]

o.dippel

RCLine User

Wohnort: Büdingen / Hessen

Beruf: Software-Developer

  • Nachricht senden

5

Samstag, 24. Juli 2010, 18:07

Hi,
das Haupt-Problem an einem Netbook sind die extrem schlechten Displays bei Sonnen-Licht.
Auf z.B. einem eeePC siehst du absolut gar nix auf dem Flugplatz.
Das mit der Echtzeit-Fähigkeit ist auch ein Problem, nicht nur die Hardware (USB, ..) sondern vor allem das Betriebs-System da kann ein kleiner Hänger tötlich sein (fürs Modell).
Angefangen hat bei uns ja auch alles mit einem PDA (Setup) und einem AVR für die Echtzeitaufgaben (ADC->...->PPM).
Wir wollten aber alles mit 'Neuteilen' aufbauen und zu der Zeit gab es noch keine wirklich günstige Netbooks.

Das mit dem Strom ist auch so eine Sache, wenn man den ganzen Tag auf dem Flugplatzt ist, ist so en Netbook-Akku auch schnell leer da die CPU die ganze Zeit am Arbeiten ist und das System nicht mal für einen kurzen Moment in irgendein Stromspar-Programm fallen darf.

Dann kommt noch das Gewicht und die Größe eines Netbooks, mit allem drum und dran (Knüppel, Sendergehäuse, Keyboard-Schublade ...) hasste da am Ende über 2Kg am Hals hängen.

Ansonsten währe das ne tolle Sache, CPU & RAM ohne Ende :ok:
Wobei mit Live-Video und und und bleibt dann auch nett mehr so viel übrig :(


:w

PS: Basteln kann man viel, aber das ganze auch ordentlich als eine Einheit zu verpacken ist schwierig.

6

Samstag, 24. Juli 2010, 19:28

Klar Gewicht ist ein Thema. Da müsste man sich ggf. etwas überlegen. Die schlechten Display sind natürlich auch doof. Dafür könnte man z.B. das Modell fotografieren und auf dem Display (in Farbe *g*) anzeigen um sicher zu sein, dass der Sender den korrekten "Modellspeicher" geladen hat. Und natürlich viele andere Dinge.

Den ganzen Tag laufen müsste das Netbook ja auch nicht. Die wenigsten Piloten fliegen 10 Stunden nonstop. Ein Lipo zum wechseln und den Netbook-Akku entfernen und gut ist''s.

Betriebssystem müsste ja auch nicht zwingend Windows sein. Viele Netbooks verkraften auch Linux und da gibt es Ansätze in Richtung Echtzeitfähigkeit. Das eine Fräse per USB ein Problem ist, ist klar. Verfahrgeschwindigkeit z.B. 1 m/Minute. Heißt in 1 Sekunde fährt das Ding 16 mm. In 1/100tel Sekunde immerhin 0,16 mm. 10 ms Verzögerung bringen also im schlimmsten Fall 0,16 m "daneben gefräst". Abgesehen davon, dass die Schrittmotoren "aus dem Takt" kommen, wenn sie unregelmäßig angesteuert werden.

Bei einer Kopplung via PPM könnte man auch ein USB-Audiodevice nutzen und dort eine "Wavetable" reinpacken. Die Dinger sollten das PPM-Signal dann sehr exakt immer und immer wieder abspielen können. Oder besser halt noch eine "richtige" Digitale Schnittstelle zum HF-Modul. Womit allerdings wohl alle "fertigen" Modellfluglösungen erst mal ausscheiden...

Ggf. könnte man auch sowas hier ausschlachten:

http://www.quantelectronic.de/default.as…cid=1&et_lid=12

Als Display "für unterwegs" dann z.B. einen digitalen Bilderrahmen in Billigausführung mit VGA-Auflösung. Die Dinger sind billig und schlagen trotzdem jedes Display von käuflichen Fernsteuerungen. Programmierung zu Hause erfolgt dann am "großen" Monitor mit angeschlossener Tastatur. Auf dem Flugfeld gäbe es dann halt nur eine eingeschränkte Benutzeroberfläche.

Ciao, Udo

7

Samstag, 24. Juli 2010, 19:45

Hallo,

Hm, ich seh nicht so richtig den Vorteil.
Rechenleistung sollte eigentlich nicht das Problem sein, falls der STM32 nicht mehr reicht, wäre in meinen Augen eher irgend ein größerer ARM mit einem embedded-Linux oder einem "echten" RT-OS (z.B. RTOS) sinnvoller, als da auf einem Netbook was zusammenzubasteln. Dort mag sich immer mal wieder was an der Hardware ändern, eine verlässliche Plattform ist was anderes. Von der Treibersituation mal ganz abgesehen.
Das Energieproblem hat Olli ja schon angesprochen. Nach 2-3 Stunden schon den Akku zu wechseln, find ich eher doof, vorallem, wenn man ein System verwenden kann, das mit deutlich unter 1W auskommt.
Den einzigen Vorteil seh ich bei der Bedienung, ein Modell läßt sich mit Tastatur sehr viel leichter einrichten, als mit einem einzelnen Drehencoder.
Aber da halt ichs dann wirklich für sinnvoller, einfach ein kleines Netbook mitzunehmen, oder die Grundeinstellungen zu Hause am Rechner zu machen.

Im Großen und ganzen gefällt mir das System so, wie es gerade ist, sehr gut. Ich würde eher Energie darauf verwenden, am vorhandenen die Kinderkrankheiten auszumerzen, als immer neuen Ideen hinterherzulaufen.

viele Grüße,
Hermann

8

Montag, 26. Juli 2010, 08:05

Hallo zusammen,

eigentlich kann ich mich nur Oll, Hermann und Björn anschliessen.
Der wesentliche Grund ist eine dauerhaft verfügbare (und gleiche) HW zu haben. Wie Hermann auch schon sagte, sollte man nicht ausreichender Rechenleistung auf einen "größeren" Prozessor ausweichen, ggf. ein RT Linux darauf adaptieren.
Momentan sehe ich aber nicht, dass die Rechenleistung nicht (mehr) ausreichen sollte. Wenn ich mir unseren RX12 anschaue, der bereits viele Funktionen integriert hat und mit einem ATmega auskommt (die STM32 Version läuft leider immer noch nicht :( ), sollten wir da in absehbarer Zeit nicht in Probleme kommen.

Zitat

Original von hoppppla
Im Großen und ganzen gefällt mir das System so, wie es gerade ist, sehr gut. Ich würde eher Energie darauf verwenden, am vorhandenen die Kinderkrankheiten auszumerzen, als immer neuen Ideen hinterherzulaufen.


Ja, da kann ich Hermann auch nur zustimmen, mir gefällt der jetzige Stand auch schon sehr gut.
Ich habe angefangen, die "Kinderkrankheiten" auszumerzen, wobei es so viele ja auch nicht sind. Geplant ist, die Hauptplatine möglichst "klein" zu gestalten, und dann auch nur eine Version für die FM6014 und MC3030. Stromversorgung und ggf. alle I/O dann auf Module. Somit kann die immer gleiche HW auch in weitere Sender eingebaut werden. Aus diversen Gründen würde ich auch ungerne vom jetzigen STM32 abweichen. "Nachteil" der Überarbeitung könnte sein, dass wir 4-lagig werden, aber bzgl. EMV und Störfestigkeit sehe ich da einen deutlichen Vorteil.

Grüße

Ralf

9

Montag, 26. Juli 2010, 16:09

Hallo Ralf,

Zitat

"Nachteil" der Überarbeitung könnte sein, dass wir 4-lagig werden, aber bzgl. EMV und Störfestigkeit sehe ich da einen deutlichen Vorteil.

Oh ja, 4-lagig wäre ein Traum :)
An Kinderkrankheuten hatte ich z.B. das Übersprechen zwischen den AD-Kanälen im Kopf :)
Auch für die Verstärker für die Knüppelpotis könnte man sich vl. noch eine praktischer Lösung überlegen
vl. können wir dafür mal wieder einen neuen Threat aufmachen :)

viele Grüße,
Hermann

o.dippel

RCLine User

Wohnort: Büdingen / Hessen

Beruf: Software-Developer

  • Nachricht senden

10

Montag, 26. Juli 2010, 17:01

Zitat

Auch für die Verstärker für die Knüppelpotis könnte man sich vl. noch eine praktischer Lösung überlegen

Wiederstände zum Centern helfen an der Stelle :-)

:w

11

Montag, 26. Juli 2010, 17:48

Hi Olli,

Zitat

Wiederstände zum Centern helfen an der Stelle :-)

hm, gegen die gegenseitige Beeinflussung? Das hoffe ich :) Man müßte nur sich mal überlegen, wie groß die sein sollten.
Das Einstellen der Verstärker werden sie wohl nicht erleichtern, oder?

viele Grüße,
Hermann

o.dippel

RCLine User

Wohnort: Büdingen / Hessen

Beruf: Software-Developer

  • Nachricht senden

12

Montag, 26. Juli 2010, 17:56

Quellcode

1
hm, gegen die gegenseitige Beeinflussung? Das hoffe ich smile Man müßte nur sich mal überlegen, wie groß die sein sollten. Das Einstellen der Verstärker werden sie wohl nicht erleichtern, oder?

Dadurch das die ADC's frei schwingend sind, ist es normal das sie von Nachbar-Kanälen beeinflusst werden.
Die Wiederstände sind relativ egal (so um die 100K würde ich nehmen).

Die Einstellung wird es nicht erleichtern !

:w