Ruby ist da, installiert, getestet und geflogen...
- Themenstarter autist
- Beginndatum
- Status
Hallo,
gestern war nun der angekündigte 1.Flug.
Zuvor hatte ich Schwierigkeiten aus verschiedenen Ursachen.
Die erste war, daß mir Jim Hall eine nicht passende .cfg für meine EasyGliderVersion zumailte. Darauf kam eine andere, die ebenfalls nicht funktionierte.
Die Ursache wiederum bestand aus einer anderen, neuen Version der Motorcontrol, als die in meinem EasyStar, was Jim Hall jedoch nicht bemerkt hatte. Er verwendete auch Daten aus der vorhandenen, alten, Easystar .cfg, weil ich den Speedsensor an beiden Modellen von unten in die Tragfläche einbaute, und damit das Teil auf dem Kopf stand.
Nach einigen Mails war alles klar. Wegen der "verflixten" Zeitverschiebung Europa-USA/Ost ging der Mailwechsel mitunter länger als verständlich und meine Ungeduld stieg. Entweder dort Nacht oder bei uns
Manchmal kam sein Mail um 09 Uhr Europa, er mußte demnach bis 03 Uhr Boston gearbeitet haben, was er auch mal schrieb.
Als alles komplett schien, war bei uns tagelang wieder Sturm und Regen.
Nun also flog der EasyGlider.
So ganz zufrieden war ich nicht, weil Ruby den Motor nicht zuschaltete.
Alle Modi konnte ich nur im Gleitflug aus größerer Höhe erfliegen. Die aber funktionierten gut
Also schickte ich nach dem Flug die .data Datei nach Boston.
Heute Morgen war die Antwort von Jim Hall da: ich hatte von 2 gleichen Anschlüssen am Ruby für das Motorsensorkabel den nicht passenden Eingang benutzt und es gibt für die neue Version angeblich noch keine Installationsbeschreibung, für deren Fehlen sich Jim Hall entschuldigte.
Leider läßt Jim Hall unter keinen Umständen Einblicke in den Quellcode zu, daß man uU. selbst Änderungen vornehmen könnte.
Ein Umstand, zu dem Chucky1978 auch schon im Voraus seine eigenen Bedenken geäußert hatte.
Ich weiß jedoch nicht, ob ich mich darin zurechtfinden könnte. Der Weg über Jim Hall ist besser.
LG
http://youtu.be/7bsw9lVrSlw
gestern war nun der angekündigte 1.Flug.
Zuvor hatte ich Schwierigkeiten aus verschiedenen Ursachen.
Die erste war, daß mir Jim Hall eine nicht passende .cfg für meine EasyGliderVersion zumailte. Darauf kam eine andere, die ebenfalls nicht funktionierte.
Die Ursache wiederum bestand aus einer anderen, neuen Version der Motorcontrol, als die in meinem EasyStar, was Jim Hall jedoch nicht bemerkt hatte. Er verwendete auch Daten aus der vorhandenen, alten, Easystar .cfg, weil ich den Speedsensor an beiden Modellen von unten in die Tragfläche einbaute, und damit das Teil auf dem Kopf stand.
Nach einigen Mails war alles klar. Wegen der "verflixten" Zeitverschiebung Europa-USA/Ost ging der Mailwechsel mitunter länger als verständlich und meine Ungeduld stieg. Entweder dort Nacht oder bei uns
Manchmal kam sein Mail um 09 Uhr Europa, er mußte demnach bis 03 Uhr Boston gearbeitet haben, was er auch mal schrieb.
Als alles komplett schien, war bei uns tagelang wieder Sturm und Regen.
Nun also flog der EasyGlider.
So ganz zufrieden war ich nicht, weil Ruby den Motor nicht zuschaltete.
Alle Modi konnte ich nur im Gleitflug aus größerer Höhe erfliegen. Die aber funktionierten gut
Also schickte ich nach dem Flug die .data Datei nach Boston.
Heute Morgen war die Antwort von Jim Hall da: ich hatte von 2 gleichen Anschlüssen am Ruby für das Motorsensorkabel den nicht passenden Eingang benutzt und es gibt für die neue Version angeblich noch keine Installationsbeschreibung, für deren Fehlen sich Jim Hall entschuldigte.
Leider läßt Jim Hall unter keinen Umständen Einblicke in den Quellcode zu, daß man uU. selbst Änderungen vornehmen könnte.
Ein Umstand, zu dem Chucky1978 auch schon im Voraus seine eigenen Bedenken geäußert hatte.
Ich weiß jedoch nicht, ob ich mich darin zurechtfinden könnte. Der Weg über Jim Hall ist besser.
LG
http://youtu.be/7bsw9lVrSlw
Zuletzt bearbeitet:
Auch ich habe vor kurzem mein Ruby erhalten, und konnte schon mal einen kurzen Einblick in das System erhaschen und erlaube mir daher mal eine Einschätzung und vorläufige Meinung.
Da ich nicht weniger auf Videos stehe, sondern mehr auf die Technischen Details versuche einzugehen, und mir imo die Zeit etwas fehlt oder eher wegläuft, ist das alles evtl. nicht ganz so detailliert wie ich es gerne hätte. Ich versuche immer noch die Anleitungen zu übersetzen um diverse Ungereimtheiten zu verstehen und vor allem nachvollziehen zu können, oder auch Diverse Dinge zu finden ;-)
Vorweg, das Ruby scheint kein wirklich neues System zu sein. Im Web konnte ich diverse Posts mit Auspack-Videos schon von Anfang 2011 finden. jedoch hat sich das ein oder andere am System geändert, was aber mehr optisch zu sein scheint.
Geändert wurde der Stromsensor. In allen Anleitungen wird noch ein anderer Stromsensor gezeigt, an dem die Kontakte für ESC und BATT anders angeordnet sind. Auch ist der Anschluss ein anderer wie es scheint. Anstelle an den MotorSense-Anschluss, wird dieser wohl an den I2C-Anschluss an geklemmt. Wie gesagt, die Anleitung beinhaltet noch einen anderen Sensor. Bisher ist aber nichts kaputt gegangen, und die Stecker passen nirgend wo anders hin, auch ist die Bezeichnung auf den Platinen entsprechend ;-) Also passt schon alles
Die andere Änderung ist der Airspeedsensor und Kompass. vermutlich nur optisch. Hier wird ein Sensor abgebildete mit beiden Anschlüssen nach vorn gerichtet. Bei mir sind sie Anschlüsse jeweils nach Vorn und der andere nach hinten.
Ich wüsste jetzt auch nicht, mit welchem System ich dieses hier vergleichen könnte. Preislich liegt es im Sektor des RVOSD, Von der Bauart ähnelt es mehr dem Eagletree, und vom Funktionsumfang wäre es jedoch mehr dem APM zugeordnet. Jedoch ist dieses System komplett Closed Source im Gegensatz zum APM. Und mit Closed Source ist definitiv eine neue und heftigere Variante gemeint. ;-)
Vergleichen fällt mir hier sehr schwer, da auch die anderen Systeme nicht mehr, oder eher schon lange nicht mehr eingesetzt habe, und dieses bisher nur von der Werkbank her kenne und mich noch in Konfigurationsbegebenheiten einarbeite wie z.B. wie wichtig die "genaue" Einhaltung der Himmelsrichtung ist. Vermutlich nur für den Hersteller, damit er anhand der geänderten Himmelsrichtung die neue Einstellung erkennt die vorgenommen wird und weniger aber auch der Bestimmung ob der Kompass funktioniert.
Aber im Grunde ist die Erfahrung im Flug größtenteils für mich erstmal Irrelevant. Das das Ding fliegen kann, und auch den Umkreis beim Autonomen landen recht gut einhält sieht man überall.
Das ganze System scheint jedoch sehr wertig zu sein. Das System wird mittels IDT-Steckern zusammen gefügt. Dank dieser ist die doch schon recht extreme Kabellänge mit etwas Fingerspitzengefühl änderbar. Hier werden die Kabel einfach nach oben aus dem Stecker gezogen, und ohne ab isolieren usw., wird der Stecker am ab gelängten Kabel wieder eingesteckt. Benötigt wird hier ein kleiner Uhrmacherschraubendreher und evtl. eine Lupe, um zu verhindern das man auf die Metallspitzen im Stecker drückt. Es wird jedoch auch hier an einer neuen Kabelserie gearbeitet. An sich finde ich das Kabel-System recht gut bzw. angemessen. Favorit ist für mich immer noch die Stecker eine Nummer größer, aber da man hier auf Krimpen komplett verzichtet, ist dieses System sehr angenehm zu nutzen.
Nachteilig finde ich die Technische Dokumentation über die PIN-Belegungen. Mir ist Anfangs direkt schon eine Klemme abgebrochen für die PPM-Verbindung, und die Kabel sind extrem leicht aus dem Stecker gekommen. Der Hersteller hat mir innerhalb weniger Stunden die Belegung des Kabels gepostet, und auch wenn man mittels Multimeter hier nachmessen kann (was ich getan habe), empfinde ich das als noch störend so wenig Informationen vorliegen zu haben. Mittels Multimeter nachmessen ist zwar relativ einfach möglich dennoch umständlich.
Für diejenigen die die Kabel evtl. kürzen möchten :
Die Kabel sind alle 1:1 geklemmt mit Ausnahme des Panels.
Da sich 1:1 aber immer relativ auslegen lässt habe ich als Beispiel ein Foto angefügt. Die Stecker sind an den Kabeln um 180° verdreht, was dadurch schnell zu einem Missverständnis führen könnte, und am Ende hat man ein Twisted-Kabel. Ausgenommen hiervon ist das Panel. Hier wird von einem 5-POL auf einen 6-POL-Stecker gegangen. Man sollte also sich vorher genau anzeichnen, welches Kabel wohin kommt, bevor man irgendwas macht.
Vor dem Einbau sollte man noch die ganzen Kontakte und Stecker sichten. viele Stecker sind auf die Platine gelötet und geklebt. Dadurch gab es einige Läufer an meinem Ruby in den Microsteckern und den Servokontakten. entfernen ließen sie sich recht leicht mit einem Skalpell. Sowas sollte zwar nicht vorkommen, aber die Kirche kann man im Dorf lassen solange dadurch kein Stecker extrem versaut wird, oder es gar zu Schäden kommt wenn man vorher nicht die Stecker inspiziert und dann mittels "Gewalt" die Stecker versucht einzustecken.
In meinem Fall habe ich das System komplett in Schrumpfschlauch eingepackt. Der Hersteller sagt, das kein Klettband verwendet werden soll, was logisch ist. Mein Klettband ist so stark, das ich nicht nur die Platine, zumindest den Expander abziehen würde, während der Rest an Ort und Stelle verbleibt, sondern ist die Platine auch nicht so extrem stabil, so das es evtl. zu schäden kommen kann. Unter- und Oberseite bestehen lediglich aus einer GfK-Platte mit 0,5mm Dicke. Da wird zwar nichts brechen, aber für die Verklebung der Stecker wäre ein Klettband in dem Fall keine gute Wahl.
Der Hersteller schickt ein Stück EPP mit, welches an zwei oder mehr Seiten mit Tesa befestigt werden kann, um so einen festen Sitz zu gewährleisten.
Mitgeliefert wird auch ein Panel, was den Zustand des Ruby von außerhalb sichtbar macht. Diese Platine ist auch mit Bohrungen zur Befestigung vorgesehen. Über die genaue Funktion des Buttons des Panels bin ich mir noch unklar, werde aber mit der Zeit bestimmt dahinter kommen.
Weiter wird ein USB-Dongle mitgeliefert. Auch dessen Funktion entzieht sich bis Dato meiner Kenntnis. Win7 erkennt keinen passenden Treiber, auch gibt es keine Software für das Ruby. Da sich der Dongle aber nur am Expander anschließen lässt, vermute ich mal um evtl. Flugrouten via USB aufzuspielen usw., ohne die SD-Card herausnehmen zu müssen.
Etwas irritierend aber eigentlich fast unwichtig ist die maximale Stromversorgung. Laut Anleitung sollte diese 4,5V nicht unterschreiten, und nicht über 5,4V liegen, wobei der beste Spannungswert zwischen 4,8V-5,2V sein soll. Auf der Platine steht jedoch 3,9V-5,6V. Eigentlich recht unwichtig. Ich denke die wenigsten 5V BECs liefern mehr als 5,2V und weniger als 4,8V. Ist nur eine Sache die mir aufgefallen ist.
Ein großes Problem meiner Meinung nach ist die Dokumentation. Es gibt hier zwar viel zu lesen, auch einige Bilder, aber ich denke keines Wegs ausreichend. Wenn man sich an die Bauanleitungen und Konfigurationen vom Hersteller hält, hat man wenige bis keine Probleme. Für eigene Projekte hingegen kann es zu starken Problemen führen.
Das Ruby wird z.B. in mehreren Versionen verschickt je nach Hardware des Anwenders bzw. Je nach Fernsteuerung. Meine Hitec Aurora wird z.B. nicht ohne weiteres unterstützt. Auch Graupner MX kann hier nicht unbedingt punkten. Problem ist in meinem Fall z.B. dass ich kein PPM-Signal abgreifbar habe, oder auch kein Spektrum-Sat habe. Hier muss ich einen Decoder dazwischen setzen.
Und Genau hier liegt meiner Meinung nach schon ein Problem durch die mangelnde Dokumentation.
Der TTRecEnc wird direkt mit 5V versorgt. Es liegen also am Ende Masse, Spannung und PPM am Ruby an. Diese Spannung wird aber nicht weitergeleitet, und an den Servoausgängen des Ruby kommen hier nur ~2V an. Würde man nun nicht nachmessen, und das BEC nun wie in der Anleitung an den THR-Kanal legen, wäre hier vermutlich ein schneller Schaden die Folge. Mit anderen Worten : Spannung vom Empfänger kommend klappt nicht. Strom vom THR-Kanal-Ausgang am Ruby klappt. Beides zusammen = nicht gut (vermutlich, testen tue ich es nicht). Das ist in meinem Fall natürlich eine Ausnahme, aber genau die könnte man umgehen, wenn man eine Dokumentation besser erstellen würde. Wie das nun bei anderen Systemen wie Futaba ausschaut, wo PPM direkt abgreifbar ist, weiß ich aus Ermangelung der Hardware nicht. Jedoch ein einfaches Abbild des Ruby mit der PIN-Bezeichnung wäre auch für solche Ausnahmefälle wie meine sehr schonend für den Geldbeutel.
Wie schon erwähnt ist das Ruby nicht für alle 2,4GHz-System geeignet. Voraussetzung ist mindestens ein PPM-Signal. Allein mit PCM kommt man hier nicht weit, und man benötigt einen Empfänger-Mod oder einen PPM-Wandler. Dieses bereitet bei mir imo noch etwas Kopfzerbrechen. Ich nutze von TT-Copter die TTRecEnc, welche eigentlich recht gut und zuverlässig ist. Bei Coptern ist diese sehr zügig und ich habe nie eine Verzögerung bemerkt. Jedoch habe ich hier Verzögerungen von einer geschätzten Sekunde. Mehr auf keinen Fall, aber die Verzögerung bezeichne ich als "Stark" und 0,5s sind es in jedem Fall. Das Servo dreht noch, während der Knüppel schon lang auf Anschlag ist.
Kann nun natürlich an meiner Konfig liegen. da noch nichts eingestellt ist usw. Jedoch sollte das Ruby, wenn auch jetzt im Funjet eingesetzt, für den TS vorkonfiguriert sein. Eine hohe Latenz an den Servos dürfte es her eigentlich nicht geben.. Wird sich herausstellen, wie das am Ende wirklich ist.
Etwas was mir weiter aufgefallen ist, was aber kein Fehler vom Ruby ist, sondern vom BEC. Ich nutze ein Hobbywing 8/15A BEC, statt das vorgeschlagene CC-BEC. Bei diesem BEC ist ein Schalter integriert, welchen ich hier in diesem Projekt abgeschnitten habe. Das sollte man nicht machen. Durch das abklemmen den Schalters, ist das BEC ständig eingeschaltet, was noch kein Problem darstellt, aber das BEC hat einen kurzen Anschaltstrom. Es gibt also kurz Spannung ab, schaltet wieder für eine halbe Sekunde ab und erneut an um dann voll einsatzbereit zu sein. Mit Schalter ist dieses Phänomen nicht gegeben, sofern das Ruby mit dem BEC-Schalter eingeschaltet wird. Durch diesen schnellen Spannungsabfall und erneutes Einschalten hat jedoch das Ruby Probleme. Aber nicht nur das Ruby, auch mein Empfänger ließ sich dadurch nicht mehr binden.. Also 8/15A BEC von Hobbywing nur mit Schalter der beim anklemmen auf OFF steht. Das Ruby macht Probleme, indem es die Servos nicht mehr ansteuert. Ist evtl. interessant zu wissen, das auch die Stromversorgung beim einschalten Stabil sein muss, da es sonst schnell zum Crash führen könnte.. kennt man ja von FY-Tech.
Waypoints habe ich mir mal angesehen, und ich bin angenehm überrascht. Das mit der Auswahl der entsprechenden Höhe finde ich etwas "kompliziert" aber ich hab mich damit noch nicht so richtig befasst.
Die Anzahl der WPs ist nahezu unbegrenzt. Die Begrenzung besteht lediglich in der Größe der SD-Card. Wenn man aber mal schaut, das eine 2GB-Karte mitgeliefert wird, und 100 WPs in einem 1KM-Radius mal gerade ~4-5KB an Speicher Verbrauchen, kann man unbegrenzt wirklich gelten lassen. WOrauf ich mir hier freue ist definitv Pfade zu fliegen. Durch GoogleEarth kann man nicht nur punkte, sondern schleifen erstellen, wo am ende bei einer kleinen Schleife es dadurch vermutlich 1000 WPs gibt. Ich bin gespannt wie sauber sich die Navigation bei dieser Sache verhält und wie genau sie ist, wenn ich später Erstellte Karte mit geflogener Karte vergleiche.
Am ende noch etwas zum Support.
Jim Hall ist wirklich wie ich merken durfte darauf aus, einen sehr guten Support zu liefern, was er auch tut. Ich finde es zwar nicht zufriedenstellend, und habe bisher alles erdenkliche Versucht etwas zufinden womit ich die Daten auslesen kann, um etwas tiefer Einblick zu bekommen, jedoch verläuft sich das im Sande, da UTE eine interne Beziehcnung ist, und ich nicht wirklich viel Ahnung von Programmierung habe.
Die längste Zeit die bisher Jim benötigte mir zu antworten Betrug 6-7 Stunden. Ich schrieb um 1900 Uhr, und bekam um 0500 eine Antwort.. Das ist definitiv ein sehr guter Wert.
Da ich nicht weniger auf Videos stehe, sondern mehr auf die Technischen Details versuche einzugehen, und mir imo die Zeit etwas fehlt oder eher wegläuft, ist das alles evtl. nicht ganz so detailliert wie ich es gerne hätte. Ich versuche immer noch die Anleitungen zu übersetzen um diverse Ungereimtheiten zu verstehen und vor allem nachvollziehen zu können, oder auch Diverse Dinge zu finden ;-)
Vorweg, das Ruby scheint kein wirklich neues System zu sein. Im Web konnte ich diverse Posts mit Auspack-Videos schon von Anfang 2011 finden. jedoch hat sich das ein oder andere am System geändert, was aber mehr optisch zu sein scheint.
Geändert wurde der Stromsensor. In allen Anleitungen wird noch ein anderer Stromsensor gezeigt, an dem die Kontakte für ESC und BATT anders angeordnet sind. Auch ist der Anschluss ein anderer wie es scheint. Anstelle an den MotorSense-Anschluss, wird dieser wohl an den I2C-Anschluss an geklemmt. Wie gesagt, die Anleitung beinhaltet noch einen anderen Sensor. Bisher ist aber nichts kaputt gegangen, und die Stecker passen nirgend wo anders hin, auch ist die Bezeichnung auf den Platinen entsprechend ;-) Also passt schon alles
Die andere Änderung ist der Airspeedsensor und Kompass. vermutlich nur optisch. Hier wird ein Sensor abgebildete mit beiden Anschlüssen nach vorn gerichtet. Bei mir sind sie Anschlüsse jeweils nach Vorn und der andere nach hinten.
Ich wüsste jetzt auch nicht, mit welchem System ich dieses hier vergleichen könnte. Preislich liegt es im Sektor des RVOSD, Von der Bauart ähnelt es mehr dem Eagletree, und vom Funktionsumfang wäre es jedoch mehr dem APM zugeordnet. Jedoch ist dieses System komplett Closed Source im Gegensatz zum APM. Und mit Closed Source ist definitiv eine neue und heftigere Variante gemeint. ;-)
Vergleichen fällt mir hier sehr schwer, da auch die anderen Systeme nicht mehr, oder eher schon lange nicht mehr eingesetzt habe, und dieses bisher nur von der Werkbank her kenne und mich noch in Konfigurationsbegebenheiten einarbeite wie z.B. wie wichtig die "genaue" Einhaltung der Himmelsrichtung ist. Vermutlich nur für den Hersteller, damit er anhand der geänderten Himmelsrichtung die neue Einstellung erkennt die vorgenommen wird und weniger aber auch der Bestimmung ob der Kompass funktioniert.
Aber im Grunde ist die Erfahrung im Flug größtenteils für mich erstmal Irrelevant. Das das Ding fliegen kann, und auch den Umkreis beim Autonomen landen recht gut einhält sieht man überall.
Das ganze System scheint jedoch sehr wertig zu sein. Das System wird mittels IDT-Steckern zusammen gefügt. Dank dieser ist die doch schon recht extreme Kabellänge mit etwas Fingerspitzengefühl änderbar. Hier werden die Kabel einfach nach oben aus dem Stecker gezogen, und ohne ab isolieren usw., wird der Stecker am ab gelängten Kabel wieder eingesteckt. Benötigt wird hier ein kleiner Uhrmacherschraubendreher und evtl. eine Lupe, um zu verhindern das man auf die Metallspitzen im Stecker drückt. Es wird jedoch auch hier an einer neuen Kabelserie gearbeitet. An sich finde ich das Kabel-System recht gut bzw. angemessen. Favorit ist für mich immer noch die Stecker eine Nummer größer, aber da man hier auf Krimpen komplett verzichtet, ist dieses System sehr angenehm zu nutzen.
Nachteilig finde ich die Technische Dokumentation über die PIN-Belegungen. Mir ist Anfangs direkt schon eine Klemme abgebrochen für die PPM-Verbindung, und die Kabel sind extrem leicht aus dem Stecker gekommen. Der Hersteller hat mir innerhalb weniger Stunden die Belegung des Kabels gepostet, und auch wenn man mittels Multimeter hier nachmessen kann (was ich getan habe), empfinde ich das als noch störend so wenig Informationen vorliegen zu haben. Mittels Multimeter nachmessen ist zwar relativ einfach möglich dennoch umständlich.
Für diejenigen die die Kabel evtl. kürzen möchten :
Die Kabel sind alle 1:1 geklemmt mit Ausnahme des Panels.
Da sich 1:1 aber immer relativ auslegen lässt habe ich als Beispiel ein Foto angefügt. Die Stecker sind an den Kabeln um 180° verdreht, was dadurch schnell zu einem Missverständnis führen könnte, und am Ende hat man ein Twisted-Kabel. Ausgenommen hiervon ist das Panel. Hier wird von einem 5-POL auf einen 6-POL-Stecker gegangen. Man sollte also sich vorher genau anzeichnen, welches Kabel wohin kommt, bevor man irgendwas macht.
Vor dem Einbau sollte man noch die ganzen Kontakte und Stecker sichten. viele Stecker sind auf die Platine gelötet und geklebt. Dadurch gab es einige Läufer an meinem Ruby in den Microsteckern und den Servokontakten. entfernen ließen sie sich recht leicht mit einem Skalpell. Sowas sollte zwar nicht vorkommen, aber die Kirche kann man im Dorf lassen solange dadurch kein Stecker extrem versaut wird, oder es gar zu Schäden kommt wenn man vorher nicht die Stecker inspiziert und dann mittels "Gewalt" die Stecker versucht einzustecken.
In meinem Fall habe ich das System komplett in Schrumpfschlauch eingepackt. Der Hersteller sagt, das kein Klettband verwendet werden soll, was logisch ist. Mein Klettband ist so stark, das ich nicht nur die Platine, zumindest den Expander abziehen würde, während der Rest an Ort und Stelle verbleibt, sondern ist die Platine auch nicht so extrem stabil, so das es evtl. zu schäden kommen kann. Unter- und Oberseite bestehen lediglich aus einer GfK-Platte mit 0,5mm Dicke. Da wird zwar nichts brechen, aber für die Verklebung der Stecker wäre ein Klettband in dem Fall keine gute Wahl.
Der Hersteller schickt ein Stück EPP mit, welches an zwei oder mehr Seiten mit Tesa befestigt werden kann, um so einen festen Sitz zu gewährleisten.
Mitgeliefert wird auch ein Panel, was den Zustand des Ruby von außerhalb sichtbar macht. Diese Platine ist auch mit Bohrungen zur Befestigung vorgesehen. Über die genaue Funktion des Buttons des Panels bin ich mir noch unklar, werde aber mit der Zeit bestimmt dahinter kommen.
Weiter wird ein USB-Dongle mitgeliefert. Auch dessen Funktion entzieht sich bis Dato meiner Kenntnis. Win7 erkennt keinen passenden Treiber, auch gibt es keine Software für das Ruby. Da sich der Dongle aber nur am Expander anschließen lässt, vermute ich mal um evtl. Flugrouten via USB aufzuspielen usw., ohne die SD-Card herausnehmen zu müssen.
Etwas irritierend aber eigentlich fast unwichtig ist die maximale Stromversorgung. Laut Anleitung sollte diese 4,5V nicht unterschreiten, und nicht über 5,4V liegen, wobei der beste Spannungswert zwischen 4,8V-5,2V sein soll. Auf der Platine steht jedoch 3,9V-5,6V. Eigentlich recht unwichtig. Ich denke die wenigsten 5V BECs liefern mehr als 5,2V und weniger als 4,8V. Ist nur eine Sache die mir aufgefallen ist.
Ein großes Problem meiner Meinung nach ist die Dokumentation. Es gibt hier zwar viel zu lesen, auch einige Bilder, aber ich denke keines Wegs ausreichend. Wenn man sich an die Bauanleitungen und Konfigurationen vom Hersteller hält, hat man wenige bis keine Probleme. Für eigene Projekte hingegen kann es zu starken Problemen führen.
Das Ruby wird z.B. in mehreren Versionen verschickt je nach Hardware des Anwenders bzw. Je nach Fernsteuerung. Meine Hitec Aurora wird z.B. nicht ohne weiteres unterstützt. Auch Graupner MX kann hier nicht unbedingt punkten. Problem ist in meinem Fall z.B. dass ich kein PPM-Signal abgreifbar habe, oder auch kein Spektrum-Sat habe. Hier muss ich einen Decoder dazwischen setzen.
Und Genau hier liegt meiner Meinung nach schon ein Problem durch die mangelnde Dokumentation.
Der TTRecEnc wird direkt mit 5V versorgt. Es liegen also am Ende Masse, Spannung und PPM am Ruby an. Diese Spannung wird aber nicht weitergeleitet, und an den Servoausgängen des Ruby kommen hier nur ~2V an. Würde man nun nicht nachmessen, und das BEC nun wie in der Anleitung an den THR-Kanal legen, wäre hier vermutlich ein schneller Schaden die Folge. Mit anderen Worten : Spannung vom Empfänger kommend klappt nicht. Strom vom THR-Kanal-Ausgang am Ruby klappt. Beides zusammen = nicht gut (vermutlich, testen tue ich es nicht). Das ist in meinem Fall natürlich eine Ausnahme, aber genau die könnte man umgehen, wenn man eine Dokumentation besser erstellen würde. Wie das nun bei anderen Systemen wie Futaba ausschaut, wo PPM direkt abgreifbar ist, weiß ich aus Ermangelung der Hardware nicht. Jedoch ein einfaches Abbild des Ruby mit der PIN-Bezeichnung wäre auch für solche Ausnahmefälle wie meine sehr schonend für den Geldbeutel.
Wie schon erwähnt ist das Ruby nicht für alle 2,4GHz-System geeignet. Voraussetzung ist mindestens ein PPM-Signal. Allein mit PCM kommt man hier nicht weit, und man benötigt einen Empfänger-Mod oder einen PPM-Wandler. Dieses bereitet bei mir imo noch etwas Kopfzerbrechen. Ich nutze von TT-Copter die TTRecEnc, welche eigentlich recht gut und zuverlässig ist. Bei Coptern ist diese sehr zügig und ich habe nie eine Verzögerung bemerkt. Jedoch habe ich hier Verzögerungen von einer geschätzten Sekunde. Mehr auf keinen Fall, aber die Verzögerung bezeichne ich als "Stark" und 0,5s sind es in jedem Fall. Das Servo dreht noch, während der Knüppel schon lang auf Anschlag ist.
Kann nun natürlich an meiner Konfig liegen. da noch nichts eingestellt ist usw. Jedoch sollte das Ruby, wenn auch jetzt im Funjet eingesetzt, für den TS vorkonfiguriert sein. Eine hohe Latenz an den Servos dürfte es her eigentlich nicht geben.. Wird sich herausstellen, wie das am Ende wirklich ist.
Etwas was mir weiter aufgefallen ist, was aber kein Fehler vom Ruby ist, sondern vom BEC. Ich nutze ein Hobbywing 8/15A BEC, statt das vorgeschlagene CC-BEC. Bei diesem BEC ist ein Schalter integriert, welchen ich hier in diesem Projekt abgeschnitten habe. Das sollte man nicht machen. Durch das abklemmen den Schalters, ist das BEC ständig eingeschaltet, was noch kein Problem darstellt, aber das BEC hat einen kurzen Anschaltstrom. Es gibt also kurz Spannung ab, schaltet wieder für eine halbe Sekunde ab und erneut an um dann voll einsatzbereit zu sein. Mit Schalter ist dieses Phänomen nicht gegeben, sofern das Ruby mit dem BEC-Schalter eingeschaltet wird. Durch diesen schnellen Spannungsabfall und erneutes Einschalten hat jedoch das Ruby Probleme. Aber nicht nur das Ruby, auch mein Empfänger ließ sich dadurch nicht mehr binden.. Also 8/15A BEC von Hobbywing nur mit Schalter der beim anklemmen auf OFF steht. Das Ruby macht Probleme, indem es die Servos nicht mehr ansteuert. Ist evtl. interessant zu wissen, das auch die Stromversorgung beim einschalten Stabil sein muss, da es sonst schnell zum Crash führen könnte.. kennt man ja von FY-Tech.
Waypoints habe ich mir mal angesehen, und ich bin angenehm überrascht. Das mit der Auswahl der entsprechenden Höhe finde ich etwas "kompliziert" aber ich hab mich damit noch nicht so richtig befasst.
Die Anzahl der WPs ist nahezu unbegrenzt. Die Begrenzung besteht lediglich in der Größe der SD-Card. Wenn man aber mal schaut, das eine 2GB-Karte mitgeliefert wird, und 100 WPs in einem 1KM-Radius mal gerade ~4-5KB an Speicher Verbrauchen, kann man unbegrenzt wirklich gelten lassen. WOrauf ich mir hier freue ist definitv Pfade zu fliegen. Durch GoogleEarth kann man nicht nur punkte, sondern schleifen erstellen, wo am ende bei einer kleinen Schleife es dadurch vermutlich 1000 WPs gibt. Ich bin gespannt wie sauber sich die Navigation bei dieser Sache verhält und wie genau sie ist, wenn ich später Erstellte Karte mit geflogener Karte vergleiche.
Am ende noch etwas zum Support.
Jim Hall ist wirklich wie ich merken durfte darauf aus, einen sehr guten Support zu liefern, was er auch tut. Ich finde es zwar nicht zufriedenstellend, und habe bisher alles erdenkliche Versucht etwas zufinden womit ich die Daten auslesen kann, um etwas tiefer Einblick zu bekommen, jedoch verläuft sich das im Sande, da UTE eine interne Beziehcnung ist, und ich nicht wirklich viel Ahnung von Programmierung habe.
Die längste Zeit die bisher Jim benötigte mir zu antworten Betrug 6-7 Stunden. Ich schrieb um 1900 Uhr, und bekam um 0500 eine Antwort.. Das ist definitiv ein sehr guter Wert.
Zu dem immer wieder zitierten Video meines EasyStar im RTH Modus:
Hier war keine Höhenbestimmung durch Feiyu erkennbar. Das Modell blieb die ganze Zeit in konstanten, modelleigenen Gleitflug bis zum Boden. Zudem war es fast windstill.
Ich habe lange geglaubt, daß Feiyu mit seinen Flugmodi höhensensitiv ist.
Das wird zwar immer wieder angedeutet, ist letztendlich leider nicht erfolgreich.
Eine Höhenkontrolle mit Höhenruder ist auch fliegerhandwerklich falsch.
Das Höhenruder steuert die Geschwindigkeit. Diese ist in engem Rahmen variabel.
Der für Flugdummies stets verständliche Spruch "Durch Ziehen gewinnt man Höhe" macht nur Sinn, wenn man einige Gechwindigkeiten wie zB " bestes Steigen" und " bester Steigwinkel" bzw "bestes Sinken" und "bester Gleitwinkel" oder "VNE" einstellen will.
Aber für alle gilt " Steigen und Fallen wird mit dem Motor bestimmt".
Ganz extrem ist das für Segelflieger. Der hat kein eigenes Steigen und demnach nur Sinken. Und wozu hat er dann sein Höhenruder??
Nun zu Feiyu.
Auch wenn behauptet wird, daß Feiyu Höhe einhalten will, kann es nicht funktionieren, wenn nicht gleichzeitig die Fluggeschwindigkeit beeinflußt wird. Und damit scheidet Feiyu aus der wertung aus, weil nur GPS-Speed ermittelt wird. Diese gilt damit nur bei Windstille.
Im Waypoint-Modus meinte ich gelegentlich eine Höheneinstellung wahrzunehmen, weil nach Umschalten in diesen Modus der Horizont im Camerabild nach unten wanderte, wenn das Modell tiefer als 200m war (Nase des Modelles geht nach oben). Und umgekehrt der Horizont nach oben ging, wenn das Modell höher war ( Nase des Modelles geht nach unten).
Das alles war jedoch unpräzis und nicht zuverlässig reproduzierbar, daß ich keine weiteren Versuche mehr machte.
Ruby geht anders an diese Technik.
Ruby hat einen Speedsensor mittels Pitotrohr und Drucksonde. Ruby bestimmt den Speed des Modelles in der umgebenden Luft.
Ruby macht Steigen und Fallen über den Motor. Das kann man Sehen und Hören. Wenn der Motor aus ist, bleibt im Gleitflug dennoch die gewünschte Fluggeschwindigkeit erhalten.
Dieses alles macht zB den Aided-Modus zu einem von mir gerne praktizierten Test:
Ich gebe einem Umstehenden den Sender in die Hand und sage ihm " nun steuer mal das Modell".
Ruby nimmt die beim Umschalten bestehende Höhe als Fix, der Airspeed ist sowieso festgelegt und der Testpilot fliegt "seine" Kurven wie gewünscht. Der Motor schaltet sich Ein und Aus wie von Ruby als notwendig erkannt. Und wenns "gefährlich" wird, läßt der Tester die Knüppel los.
Fortsetzung folgt.
HTML:
http://www.youtube.com/watch?v=OluKJuk_z00Ich habe lange geglaubt, daß Feiyu mit seinen Flugmodi höhensensitiv ist.
Das wird zwar immer wieder angedeutet, ist letztendlich leider nicht erfolgreich.
Eine Höhenkontrolle mit Höhenruder ist auch fliegerhandwerklich falsch.
Das Höhenruder steuert die Geschwindigkeit. Diese ist in engem Rahmen variabel.
Der für Flugdummies stets verständliche Spruch "Durch Ziehen gewinnt man Höhe" macht nur Sinn, wenn man einige Gechwindigkeiten wie zB " bestes Steigen" und " bester Steigwinkel" bzw "bestes Sinken" und "bester Gleitwinkel" oder "VNE" einstellen will.
Aber für alle gilt " Steigen und Fallen wird mit dem Motor bestimmt".
Ganz extrem ist das für Segelflieger. Der hat kein eigenes Steigen und demnach nur Sinken. Und wozu hat er dann sein Höhenruder??
Nun zu Feiyu.
Auch wenn behauptet wird, daß Feiyu Höhe einhalten will, kann es nicht funktionieren, wenn nicht gleichzeitig die Fluggeschwindigkeit beeinflußt wird. Und damit scheidet Feiyu aus der wertung aus, weil nur GPS-Speed ermittelt wird. Diese gilt damit nur bei Windstille.
Im Waypoint-Modus meinte ich gelegentlich eine Höheneinstellung wahrzunehmen, weil nach Umschalten in diesen Modus der Horizont im Camerabild nach unten wanderte, wenn das Modell tiefer als 200m war (Nase des Modelles geht nach oben). Und umgekehrt der Horizont nach oben ging, wenn das Modell höher war ( Nase des Modelles geht nach unten).
Das alles war jedoch unpräzis und nicht zuverlässig reproduzierbar, daß ich keine weiteren Versuche mehr machte.
Ruby geht anders an diese Technik.
Ruby hat einen Speedsensor mittels Pitotrohr und Drucksonde. Ruby bestimmt den Speed des Modelles in der umgebenden Luft.
Ruby macht Steigen und Fallen über den Motor. Das kann man Sehen und Hören. Wenn der Motor aus ist, bleibt im Gleitflug dennoch die gewünschte Fluggeschwindigkeit erhalten.
Dieses alles macht zB den Aided-Modus zu einem von mir gerne praktizierten Test:
Ich gebe einem Umstehenden den Sender in die Hand und sage ihm " nun steuer mal das Modell".
Ruby nimmt die beim Umschalten bestehende Höhe als Fix, der Airspeed ist sowieso festgelegt und der Testpilot fliegt "seine" Kurven wie gewünscht. Der Motor schaltet sich Ein und Aus wie von Ruby als notwendig erkannt. Und wenns "gefährlich" wird, läßt der Tester die Knüppel los.
Fortsetzung folgt.
HTML:
Zuletzt bearbeitet:
Fortsetzung
War bis jetzt die automatische Landung beschrieben, wie sie in Natur und auch im Video alle Betrachter verblüffend beeindruckt, habe ich heute die Funktion "Aided" ( mittlere Schalterstellung) genutzt.
Mich interessierte, wie es bei Schnee in einer bestimmten Nachbargegend aussieht.
Also Modell ( Easystar) gestartet und auf ca 150m steigen lassen. "Aided Modus" aktiviert und das Modell etwa auf den Kurs gerichtet, den es die nächsten 5 Minuten fliegen soll. Dann beide Hände in die warmen Hosentaschen gesteckt und nur noch in die Brille geschaut.
Ruby machts. Ruby hält die Höhe plus minus 5m und die Geschwindigkeit.
Es macht unheimlich Spaß, ohne eigenes Zutun die Landschaft unter sich durchziehen zu sehen.
Unwillkürlich vergleiche ich mit meinem Feiyu31. FY macht ähnliches, bei mir jedoch nicht in der Präzision der Richtung und schon gar nicht in der konstanten Höhe und Geschwindigkeit.
Am Ziel angekommen lasse ich noch wegen des Videos einige Kreise automatisch abfliegen und dann gehts schräg an mir vorbei etliche Minuten mit "Aided" in eine andere Gegend.
Leider muß ich wegen sich leerendem Lipo umdrehen und mit "RTH" kurvt der EasyStar Richtung Startplatz. Wieder die Hände in den warmen Hosentaschen.
Mein letzter Befehl ist "Autoland" und schon beginnt Ruby mit den Landevorbereitungen, Kreisen und Höhenabbau, und der abschließenden Landung nach 22 Minuten.
Die Hände in den Hosentaschen.
Das war knapp: der 2300 Lipo nimmt abends beim Laden 2000 mA auf.
Aber es war richtig schön
War bis jetzt die automatische Landung beschrieben, wie sie in Natur und auch im Video alle Betrachter verblüffend beeindruckt, habe ich heute die Funktion "Aided" ( mittlere Schalterstellung) genutzt.
Mich interessierte, wie es bei Schnee in einer bestimmten Nachbargegend aussieht.
Also Modell ( Easystar) gestartet und auf ca 150m steigen lassen. "Aided Modus" aktiviert und das Modell etwa auf den Kurs gerichtet, den es die nächsten 5 Minuten fliegen soll. Dann beide Hände in die warmen Hosentaschen gesteckt und nur noch in die Brille geschaut.
Ruby machts. Ruby hält die Höhe plus minus 5m und die Geschwindigkeit.
Es macht unheimlich Spaß, ohne eigenes Zutun die Landschaft unter sich durchziehen zu sehen.
Unwillkürlich vergleiche ich mit meinem Feiyu31. FY macht ähnliches, bei mir jedoch nicht in der Präzision der Richtung und schon gar nicht in der konstanten Höhe und Geschwindigkeit.
Am Ziel angekommen lasse ich noch wegen des Videos einige Kreise automatisch abfliegen und dann gehts schräg an mir vorbei etliche Minuten mit "Aided" in eine andere Gegend.
Leider muß ich wegen sich leerendem Lipo umdrehen und mit "RTH" kurvt der EasyStar Richtung Startplatz. Wieder die Hände in den warmen Hosentaschen.
Mein letzter Befehl ist "Autoland" und schon beginnt Ruby mit den Landevorbereitungen, Kreisen und Höhenabbau, und der abschließenden Landung nach 22 Minuten.
Die Hände in den Hosentaschen.
Das war knapp: der 2300 Lipo nimmt abends beim Laden 2000 mA auf.
Aber es war richtig schön
Fortsetzung
Hier ist ein Video zum gestrigen Bericht. Das im Bericht erwähnte Video habe ich leider aus Versehen gelöscht und Löschungen aus der SD-Card werden bei Win7 nicht im Papierkorb aufgefangen. Ja, es kommt ein entsprechender Hinweis
Ich hatte 2 Flüge gemacht und aufgezeichnet. Entschuldigt bitte die jetzige Differenz zum Text.
Die Temperatur war -4C, der Wind 4 Bft aus NO, deshalb auch mäßige Turbulenz gerade in der gewählten Flughöhe.
Interessant ist natürlich der Aided-Mode, bei dem das Modell die Höhe automatisch einhält ( na ja plus-minus ein paar Meter), egal was ich mit dem Seitenruder( Querruder) steuere.
Wenn man die Senderknüppel losläßt, hält das Modell Richtung und Höhe bis zur nächsten Änderung.
Jim Hall hat mir geschrieben, daß er mit Modellen nur mit Seitenruder nie zufrieden ist. Er möchte gerne Modelle mit Querruder.
Ich kann das bestätigen, mein Easyglider liegt wie ein Brett in der Luft. Also warum dann dieses Video nicht mit dem EasyGlider?
Ich habe im Moment keinen so guten Videokontakt und muß beim EasyGlider die Sendeantenne nach unten aus dem Rumpf herausführen. Das ist aber noch nicht fertig und dauert noch.
Weiter interessant ist eine .cfg Änderung, die mir Jim Hall diese Tage hat zukommen lassen, nach dem ich neulich eine Lande-Kollision mit meinem Antennenmast hatte, da Ruby exakt bei mir landen wollte ( war ja auch so programmiert), und ich einen Schritt zur Seite machte, aber vergaß, daß hinter mir die Antenne steht Ich hatte die Brille nicht auf. Na ja, Schaum ist geduldig.
Im heutigen Video hält Ruby diesen Sicherheitsabstand ein.
Überhaupt hat Jim Hall einen hohen sicherheitsstandart.
ZB hat er bei neuen Ruby´s die Reichweite auf 1 km begrenzt. Ab da geht der Failsafe los. Dh, das Modell kehrt im RTH-Modus zurück.
Erst wenn alles funktioniert, und ihm das entsprechende data zugemailt wird, sendet er ein weiteres .cfg mit der Freigabe zurück.
Dann ist alles frei, so wie bei mir.
LG
http://www.youtube.com/watch?v=rJYIvd3fCA0
Hier ist ein Video zum gestrigen Bericht. Das im Bericht erwähnte Video habe ich leider aus Versehen gelöscht und Löschungen aus der SD-Card werden bei Win7 nicht im Papierkorb aufgefangen. Ja, es kommt ein entsprechender Hinweis
Ich hatte 2 Flüge gemacht und aufgezeichnet. Entschuldigt bitte die jetzige Differenz zum Text.
Die Temperatur war -4C, der Wind 4 Bft aus NO, deshalb auch mäßige Turbulenz gerade in der gewählten Flughöhe.
Interessant ist natürlich der Aided-Mode, bei dem das Modell die Höhe automatisch einhält ( na ja plus-minus ein paar Meter), egal was ich mit dem Seitenruder( Querruder) steuere.
Wenn man die Senderknüppel losläßt, hält das Modell Richtung und Höhe bis zur nächsten Änderung.
Jim Hall hat mir geschrieben, daß er mit Modellen nur mit Seitenruder nie zufrieden ist. Er möchte gerne Modelle mit Querruder.
Ich kann das bestätigen, mein Easyglider liegt wie ein Brett in der Luft. Also warum dann dieses Video nicht mit dem EasyGlider?
Ich habe im Moment keinen so guten Videokontakt und muß beim EasyGlider die Sendeantenne nach unten aus dem Rumpf herausführen. Das ist aber noch nicht fertig und dauert noch.
Weiter interessant ist eine .cfg Änderung, die mir Jim Hall diese Tage hat zukommen lassen, nach dem ich neulich eine Lande-Kollision mit meinem Antennenmast hatte, da Ruby exakt bei mir landen wollte ( war ja auch so programmiert), und ich einen Schritt zur Seite machte, aber vergaß, daß hinter mir die Antenne steht
Ich hatte die Brille nicht auf. Na ja, Schaum ist geduldig.Im heutigen Video hält Ruby diesen Sicherheitsabstand ein.
Überhaupt hat Jim Hall einen hohen sicherheitsstandart.
ZB hat er bei neuen Ruby´s die Reichweite auf 1 km begrenzt. Ab da geht der Failsafe los. Dh, das Modell kehrt im RTH-Modus zurück.
Erst wenn alles funktioniert, und ihm das entsprechende data zugemailt wird, sendet er ein weiteres .cfg mit der Freigabe zurück.
Dann ist alles frei, so wie bei mir.
LG
http://www.youtube.com/watch?v=rJYIvd3fCA0
Zuletzt bearbeitet:
Hallo,
derselbe Flug in Ruby´s uThereGroundControl, ausgelesen aus der MicroSD im Ruby Expander.
http://youtu.be/6LCG6DYJcYc
derselbe Flug in Ruby´s uThereGroundControl, ausgelesen aus der MicroSD im Ruby Expander.
http://youtu.be/6LCG6DYJcYc
Hi Mumba,
sehr interessant. Der X8 wirkt riesig, ist es evtl auch. Kompliment.
Wie willst Du den in die Luft bekommen? Nach dem Bildbericht vor einiger Zeit betr. einer Handverletzung durch einen Pusher, habe ich Respekt. Meinen EasyGlider (2 Motore, 1,8 kg) muß ich nach einer SchulterOP mit dem Gummikatapult starten, was jedoch gut funktioniert. Das wäre auch was für den X8.
Ich habe in der Nacht X8 gegooglet und bin jetzt gespannt auf Deine Flüge. Wo bist Du denn zu Hause?
Hat Dir Jim Hall eine spezielle Version .cfg für den X8 gemacht? Die für den Funjet passt wohl nicht?
Wenn schon jetzt alles funktioniert wie Servozuordnung, die konträren Servobewegungen beim Neigen und Rollen usw ist es Bestens.
Schreib mal wieder..mit Bildern
LG
sehr interessant. Der X8 wirkt riesig, ist es evtl auch. Kompliment.
Wie willst Du den in die Luft bekommen? Nach dem Bildbericht vor einiger Zeit betr. einer Handverletzung durch einen Pusher, habe ich Respekt. Meinen EasyGlider (2 Motore, 1,8 kg) muß ich nach einer SchulterOP mit dem Gummikatapult starten, was jedoch gut funktioniert. Das wäre auch was für den X8.
Ich habe in der Nacht X8 gegooglet und bin jetzt gespannt auf Deine Flüge. Wo bist Du denn zu Hause?
Hat Dir Jim Hall eine spezielle Version .cfg für den X8 gemacht? Die für den Funjet passt wohl nicht?
Wenn schon jetzt alles funktioniert wie Servozuordnung, die konträren Servobewegungen beim Neigen und Rollen usw ist es Bestens.
Schreib mal wieder..mit Bildern
LG
Hey Autist,
ja der X8 ist schon gewaltig
Ein Handstart ist aber problemlos möglich, genug Power vorrausgesetzt. Falls es mir doch zu eng mit meiner Hand werden sollte, werde ich ihn auch per Katapult starten.
Ich bin südlich von München zuhause, zwischen Holzkirchen und Miesbach.
Jim hat mir eine abgewandelte .cfg vom Zephyr geschickt. Für die ersten Flüge müsste die funktionieren, danach wenn Jim die Flugdaten hat schreibt er mir eine auf den X8 zugeschnittene. Er meinte 3-4 mal wird er sie ändern müssen bis Ruby perfekt fliegt.....
Er ist selber ganz heiss drauf da Ruby noch nie in einem X8 geflogen ist.
Servozuordnung etc. funktioniert am Boden einwandfrei.
Bis zum Erstflug wirds aber noch ein wenig dauern.... die liebe Zeit....immer zu wenig davon....
Ist aber halb so schlimm, dann ist bis zum Erstflug wenigstens auch das RubyOSD released und hoffentlich auch bei mir
Ca. 3-4 Wochen wird es noch dauern bis es raus kommt. Die Infos und Bilder von Jim sehen vielversprechend aus.
Bilder folgen wenns weiter geht
Gruss
Marco
ja der X8 ist schon gewaltig
Ein Handstart ist aber problemlos möglich, genug Power vorrausgesetzt. Falls es mir doch zu eng mit meiner Hand werden sollte, werde ich ihn auch per Katapult starten.
Ich bin südlich von München zuhause, zwischen Holzkirchen und Miesbach.
Jim hat mir eine abgewandelte .cfg vom Zephyr geschickt. Für die ersten Flüge müsste die funktionieren, danach wenn Jim die Flugdaten hat schreibt er mir eine auf den X8 zugeschnittene. Er meinte 3-4 mal wird er sie ändern müssen bis Ruby perfekt fliegt.....
Er ist selber ganz heiss drauf da Ruby noch nie in einem X8 geflogen ist.
Servozuordnung etc. funktioniert am Boden einwandfrei.
Bis zum Erstflug wirds aber noch ein wenig dauern.... die liebe Zeit....immer zu wenig davon....
Ist aber halb so schlimm, dann ist bis zum Erstflug wenigstens auch das RubyOSD released und hoffentlich auch bei mir
Ca. 3-4 Wochen wird es noch dauern bis es raus kommt. Die Infos und Bilder von Jim sehen vielversprechend aus.
Bilder folgen wenns weiter geht
Gruss
Marco
Fortsetzung
Ruby AidedModus
Nun ist RUBY #3 auch fertig. Eingebaut in einen EasyStar ist es für einen Freund im Vogtland, der eine Schulklasse betreut, die das Thema "Fliegen" abhandelt.
Besonders der Modus "Aided" eignet sich hervorragend für die Einführung in Fernlenk-Modellfliegen. Man braucht kein Lehrer-Schüler System.
Ruby merkt sich die Flughöhe und die Flugrichtung. Ruby regelt selbstständig den Motor, um auf der Höhe zu bleiben, egal was für Kurven geflogen werden.
Wer den Sender in der Hand hält, kann Kreisen und Kurven, wie er will. Das Modell bleibt oben.
Ruby hält auch unbeirrt die zuletzt eingegebene Richtung, wie wenn Ruby auf einen GPS-Punkt zufliegen würde ( vielleicht tut er das auch? )
Diese Eigenschaft verleiht dem FPV-Fliegen eine besondere Bequemlichkeit.
Man kann in aller Ruhe die Landschaft beobachten, während das Modell darüberfliegt.
Wenn gewünscht--eine Richtungsänderung, und schon wieder geht es im neuen Blickfeld weiter.
Ich hatte Ruby am 21.02. geordert, am 25.02 war die Sendung hier.( http://www.dhl-usa.com/en/express/tracking.shtml?brand=DHL&AWB=9408572762 ).
Der Erstflug verzögerte sich, dh. Fliegen ging schon, aber nur im Manual-Modus. Ruby verweigerte die Preflight-Bestätigung.
Jim Hall diagnostizierte eine Fehlfunktion des Magnetsensors.
Ich sollte eine "magnetometer calibration" durchführen.
Dazu kopiert man eine "calibration_data_recording_settings" Datei auf die Micro-SD und dreht sich in freiem und ungestörtem Gelände mit eingeschaltetem TX/RX in N-E-S-W . Die ermittelten Daten werden auf der Micro-SD gespeichert und an Jim Hall gesendet.
Das war gestern Mittag. Am Abend war die UThere Airborne Configuration per Mail hier.
Nach der Installation macht Ruby nun die Preflight-Bestätigung wie gewünscht.
Er schrieb mir dazu: "I'm sorry you had to take the extra trouble to do that. It should never be necessary, but for some reason I don't yet understand, it often seems to be needed when Ruby is shipped overseas."
Heute Nachmittag werde ich es im Flug testen.
LG
16:00 Testflug erfolgreich. alles OK.
Ruby AidedModus
Nun ist RUBY #3 auch fertig. Eingebaut in einen EasyStar ist es für einen Freund im Vogtland, der eine Schulklasse betreut, die das Thema "Fliegen" abhandelt.
Besonders der Modus "Aided" eignet sich hervorragend für die Einführung in Fernlenk-Modellfliegen. Man braucht kein Lehrer-Schüler System.
Ruby merkt sich die Flughöhe und die Flugrichtung. Ruby regelt selbstständig den Motor, um auf der Höhe zu bleiben, egal was für Kurven geflogen werden.
Wer den Sender in der Hand hält, kann Kreisen und Kurven, wie er will. Das Modell bleibt oben.
Ruby hält auch unbeirrt die zuletzt eingegebene Richtung, wie wenn Ruby auf einen GPS-Punkt zufliegen würde ( vielleicht tut er das auch? )
Diese Eigenschaft verleiht dem FPV-Fliegen eine besondere Bequemlichkeit.
Man kann in aller Ruhe die Landschaft beobachten, während das Modell darüberfliegt.
Wenn gewünscht--eine Richtungsänderung, und schon wieder geht es im neuen Blickfeld weiter.
Ich hatte Ruby am 21.02. geordert, am 25.02 war die Sendung hier.( http://www.dhl-usa.com/en/express/tracking.shtml?brand=DHL&AWB=9408572762 ).
Der Erstflug verzögerte sich, dh. Fliegen ging schon, aber nur im Manual-Modus. Ruby verweigerte die Preflight-Bestätigung.
Jim Hall diagnostizierte eine Fehlfunktion des Magnetsensors.
Ich sollte eine "magnetometer calibration" durchführen.
Dazu kopiert man eine "calibration_data_recording_settings" Datei auf die Micro-SD und dreht sich in freiem und ungestörtem Gelände mit eingeschaltetem TX/RX in N-E-S-W . Die ermittelten Daten werden auf der Micro-SD gespeichert und an Jim Hall gesendet.
Das war gestern Mittag. Am Abend war die UThere Airborne Configuration per Mail hier.
Nach der Installation macht Ruby nun die Preflight-Bestätigung wie gewünscht.
Er schrieb mir dazu: "I'm sorry you had to take the extra trouble to do that. It should never be necessary, but for some reason I don't yet understand, it often seems to be needed when Ruby is shipped overseas."
Heute Nachmittag werde ich es im Flug testen.
LG
16:00 Testflug erfolgreich. alles OK.
Zuletzt bearbeitet:
Fortsetzung:
auch der trübe Winter konnte mich nicht am Ruby-Fliegen hindern.
Inzwischen ergaben sich einige Änderungen für das Modell EasyGlider:
1) Flughöhe
Jim Hall hat im Rahmen der FAA-Richtlinien für Modelle (operations to below 400 feet above ground level) etwa 110m eingestellt.
Dies gilt für Waypoints, RTH, Loiter.
Auf meinen persönlichen Wunsch hat er die Höhe auf 300m geändert.
Warum? Weil die Qualität der Videoübertragung mit zunehmender Höhe wesentlich besser wird.
2) Schaltermodus
normalerweise ist Schalter unten ( zum Bediener gerichtet) Manual, Schalter Mitte ist Aided und Schalterstellung oben ( vom Bediener weggerichtet) ist Autonomous.
Hier hat Jim Hall nun als 1.Dip den Modus RTH für mich installiert.
Warum? Wenn die Sicht grenzwertig wird, nützt dem Kontrolleur und mir Loiter ( Kreisen) gar nichts.
Da sollte das Modell nach Hause, und zwar mit einem Dip Impuls, da man mehrere doch gelegentlich mal verhauen kann.
Der Befehl muß kommen!
Die Schalterposition ist sicherer als Dip mit Abzählen. ( RTH wären seither 2 Dips)
Der Modus Loiter kommt nun mit 2 Dips.
Für das Modell EasyStar haben wir die Höhe auf 110m belassen, jedoch die Schalterfunktion wie oben beschrieben geändert.
Fortsetzung folgt
LG
auch der trübe Winter konnte mich nicht am Ruby-Fliegen hindern.
Inzwischen ergaben sich einige Änderungen für das Modell EasyGlider:
1) Flughöhe
Jim Hall hat im Rahmen der FAA-Richtlinien für Modelle (operations to below 400 feet above ground level) etwa 110m eingestellt.
Dies gilt für Waypoints, RTH, Loiter.
Auf meinen persönlichen Wunsch hat er die Höhe auf 300m geändert.
Warum? Weil die Qualität der Videoübertragung mit zunehmender Höhe wesentlich besser wird.
2) Schaltermodus
normalerweise ist Schalter unten ( zum Bediener gerichtet) Manual, Schalter Mitte ist Aided und Schalterstellung oben ( vom Bediener weggerichtet) ist Autonomous.
Hier hat Jim Hall nun als 1.Dip den Modus RTH für mich installiert.
Warum? Wenn die Sicht grenzwertig wird, nützt dem Kontrolleur und mir Loiter ( Kreisen) gar nichts.
Da sollte das Modell nach Hause, und zwar mit einem Dip Impuls, da man mehrere doch gelegentlich mal verhauen kann.
Der Befehl muß kommen!
Die Schalterposition ist sicherer als Dip mit Abzählen. ( RTH wären seither 2 Dips)
Der Modus Loiter kommt nun mit 2 Dips.
Für das Modell EasyStar haben wir die Höhe auf 110m belassen, jedoch die Schalterfunktion wie oben beschrieben geändert.
Fortsetzung folgt
LG
Zuletzt bearbeitet:
Hallo
Ich springe vermutlich auch auf den Ruby-Vogel auf. Klingt toll und echt tolle Unterstützung. Das man nicht alle Parameter selbst einstellen kann scheint zwar ein Minus zu sein. Für mich persönlich ist es doch eher ein Plus. Ich bin weder Aeronautiker noch Mathematiker. Und Lust am Tüfteln auch nicht - ich will fliegen. Und dabei eine solch massive Unterstützung vom Profi zu erhalten ist mir sehr sympatisch!
Das mit dem OSD scheint gut zu kommen. Habe von Jim ein Mail erhalten mit Screenshots (vom Board und vom OSD). Für ausgewählte Leute ist es sogar erhältlich. Für mich tolle Features: Der künstliche Horizont kann je nach Lage der Kamera dem tatsächlichen Horizont angeglichen werden. Und viele Infos werden erst eingeblendet, wenn sie von Belange sind (quasi Alarmierung). Und man kann mehrere Screen definieren und während dem Flug wechseln. Also eine zum Aussicht geniessen, eine zum navigieren und eine mit allen Infos - oder so.
Da ich zusätzlich noch auf Frsky Taranis warte, kann ich auch noch auf das OSD warten.
Es wird übrigens noch mehr geben. Auch eine 2Weg Datenübertragung und eine Steuerung vom Compi. Das gibt dan eine GC wie beim APM. Leider scheint im Moment die Frequenz auf das 900er Band beschränkt zu sein. Insbesondere bei uns in CH ist das ein NoGo (Mobile-Netz).
Ich springe vermutlich auch auf den Ruby-Vogel auf. Klingt toll und echt tolle Unterstützung. Das man nicht alle Parameter selbst einstellen kann scheint zwar ein Minus zu sein. Für mich persönlich ist es doch eher ein Plus. Ich bin weder Aeronautiker noch Mathematiker. Und Lust am Tüfteln auch nicht - ich will fliegen. Und dabei eine solch massive Unterstützung vom Profi zu erhalten ist mir sehr sympatisch!
Das mit dem OSD scheint gut zu kommen. Habe von Jim ein Mail erhalten mit Screenshots (vom Board und vom OSD). Für ausgewählte Leute ist es sogar erhältlich. Für mich tolle Features: Der künstliche Horizont kann je nach Lage der Kamera dem tatsächlichen Horizont angeglichen werden. Und viele Infos werden erst eingeblendet, wenn sie von Belange sind (quasi Alarmierung). Und man kann mehrere Screen definieren und während dem Flug wechseln. Also eine zum Aussicht geniessen, eine zum navigieren und eine mit allen Infos - oder so.
Da ich zusätzlich noch auf Frsky Taranis warte, kann ich auch noch auf das OSD warten.
Es wird übrigens noch mehr geben. Auch eine 2Weg Datenübertragung und eine Steuerung vom Compi. Das gibt dan eine GC wie beim APM. Leider scheint im Moment die Frequenz auf das 900er Band beschränkt zu sein. Insbesondere bei uns in CH ist das ein NoGo (Mobile-Netz).
Welche kann man denn überhaupt selber einstellen?
Ich frag' mich was passiert wenn "der Schöpfer" irgendwann nicht mehr ist/kann/will? Alles Schrott?
Sobald der Vogel mal gecrasht ist, auch wenn nur leicht, kann man ihn getrost gemeinsam mit Rubi in die Tonne kippen - weil man selbst nichts mehr anpassen kann.
Oder sehe ich das falsch?
Ich frag' mich was passiert wenn "der Schöpfer" irgendwann nicht mehr ist/kann/will? Alles Schrott?
Sobald der Vogel mal gecrasht ist, auch wenn nur leicht, kann man ihn getrost gemeinsam mit Rubi in die Tonne kippen - weil man selbst nichts mehr anpassen kann.
Oder sehe ich das falsch?
Das siehst Du nicht ganz falsch. Habe selbst eine Firma und bin Schöpfer von fast Allem. Da fragt man sich schon, was passiert wenn man vom Flieger erschlagen wird. Und das ist der Vorteil von einer Firma - es wird weiter gehen.
Wenn der Businesscase stimmt, dann wird die Firma (egal ob Jim keine Lust mehr hat oder kein Geld) verkauft und es geht irgendwie weiter. Wenn der Businesscase nicht stimmt, wird auch Futaba oder all die anderen niemand mehr kaufen und der Support wird dort auch zum Erliegen kommen. Zwar sind die Firmen deutlich grösser als uThere, doch die sind gerade desswegen oft schneller im Boden. Bei Jim ist es wie bei einem Vater und seinem eigenen Kind. Der wird sich für "sein Ding" stärker einsetzen als jeder Angestelter bei renomierten RC-Firmen. In der CH ist es zudem oft so, dass bei Insolvenzen ohne Geschäftsweiterführung, die Sourcen an die Gläubiger und Lizenznehmer offengelegt werden. Daher mache ich mich um den Part erst mal keine Sorgen.
Und so wie ich es bisher gelesen und verstanden habe, kann man im Moment nichts selbst machen. So wie ich das aber auf der Homepage lese, ist Ruby noch im Beta-Stadium. Und wenn die durch ist, wird man via GC schon Änderungen vornehmen können. Ich könnte mir da Switch-Einstellungen, RX-Kanäle, AGL und solches Zeugs vorstellen. Werte zur Flugdynamik dann wohl eher weniger. Selbst am Source rumfummeln wie bei APM, das wird wohl nie gehen.
Damit meine Crashs hoffentlich nicht so übel ausfallen wie von Dir beschrieben, wird mein Ruby-Projekt ein EPP-Flügel sein.
Wenn der Businesscase stimmt, dann wird die Firma (egal ob Jim keine Lust mehr hat oder kein Geld) verkauft und es geht irgendwie weiter. Wenn der Businesscase nicht stimmt, wird auch Futaba oder all die anderen niemand mehr kaufen und der Support wird dort auch zum Erliegen kommen. Zwar sind die Firmen deutlich grösser als uThere, doch die sind gerade desswegen oft schneller im Boden. Bei Jim ist es wie bei einem Vater und seinem eigenen Kind. Der wird sich für "sein Ding" stärker einsetzen als jeder Angestelter bei renomierten RC-Firmen. In der CH ist es zudem oft so, dass bei Insolvenzen ohne Geschäftsweiterführung, die Sourcen an die Gläubiger und Lizenznehmer offengelegt werden. Daher mache ich mich um den Part erst mal keine Sorgen.
Und so wie ich es bisher gelesen und verstanden habe, kann man im Moment nichts selbst machen. So wie ich das aber auf der Homepage lese, ist Ruby noch im Beta-Stadium. Und wenn die durch ist, wird man via GC schon Änderungen vornehmen können. Ich könnte mir da Switch-Einstellungen, RX-Kanäle, AGL und solches Zeugs vorstellen. Werte zur Flugdynamik dann wohl eher weniger. Selbst am Source rumfummeln wie bei APM, das wird wohl nie gehen.
Damit meine Crashs hoffentlich nicht so übel ausfallen wie von Dir beschrieben, wird mein Ruby-Projekt ein EPP-Flügel sein.
Soweit ich das sehe, ist uThere eine One-Man-Show. Leider ist das aber ein Produkt, das ohne Support nicht funktioniert. In so fern unterscheidet es sich schon etwas zu Produkten anderer Firmen - die an sich von sich aus funktionieren und verwendbar bzw. übertragbar sind.
Ein fabrikneues oder auch abgestimmtes Ruby kann man für nichts anderes mehr einsetzen. Auch nicht für ein Baugleiches Modell mit allen seinen Fertigungs- und Zusammenbau-Toleranzen und -fehler, Gewicht, Trimmung, u.s.w.
Eine Futaba-Funke kann man auch Jahrzehnte nach deren Konkurs noch verwenden. Ganz ohne Support.
Und wenn der "Businesscase" einst nicht stimmt, was dann ohne Support? 350,- für die Tonne weil nicht mehr verwendbar weil sich mein Vogel wegen einer härteren Landung ein bisschen verzogen hat?
Ein fabrikneues oder auch abgestimmtes Ruby kann man für nichts anderes mehr einsetzen. Auch nicht für ein Baugleiches Modell mit allen seinen Fertigungs- und Zusammenbau-Toleranzen und -fehler, Gewicht, Trimmung, u.s.w.
Eine Futaba-Funke kann man auch Jahrzehnte nach deren Konkurs noch verwenden. Ganz ohne Support.
Und wenn der "Businesscase" einst nicht stimmt, was dann ohne Support? 350,- für die Tonne weil nicht mehr verwendbar weil sich mein Vogel wegen einer härteren Landung ein bisschen verzogen hat?
- Status
