Ich hatte sowas mal bei nem kleinen Dymond-Motor. Durch zu viel biegen an den Anschlusskabeln ist die Verbindung zum angelöteten Kupferlackdraht gebrochen.
Druckbare Version
Ich hatte sowas mal bei nem kleinen Dymond-Motor. Durch zu viel biegen an den Anschlusskabeln ist die Verbindung zum angelöteten Kupferlackdraht gebrochen.
Hallo
Da ich nicht genau weiß welche Werte ich als offset für Xacc und Yacc eingeben soll habe ich mir dir Quellcode angeschaut und vorläufig eine Zeile in der ACC subroutine hinzugefügt dir mir die Werte im Stillstand (Waagerecht und ohne Motoren) gezeigt hat: 520 fur Xacc und 512 fur Yacc. Ok (Zeile in Quellcode wieder weg). Gespeichert werden diese Werte minus 384 da Willa alle Werte als byte in Eeprom schreiben lässt und vielleicht höhere offset Werte auftreten können.
So verstehe ich dass mein offset Problem gelöst sein sollte und habe wieder versucht es zum fliegen zu bringen aber ohne Erfolg. Meine DLX schaukelt beim starten wild (Acro oder Hover mode und bis 3-4 m Höhe) und muss immer wieder notwendig landen. IMU zeigt richtige Werte.
Hat jemand Ahnung was es überhaupt sein kann ?
Gruß,
Hans
die werte stimmen im Flug wahrscheinlich nicht mehr. "waagerecht" stehen und wirklich waagerecht fliegen ist meist noch ein Unterschied.Zitat:
die Werte im Stillstand (Waagerecht und ohne Motoren) gezeigt hat: 520 fur Xacc und 512 fur Yacc
Nein, ohne Video ist es schwer. Aber höchstwahrscheinlich sinds wieder die regler.Zitat:
Hat jemand Ahnung was es überhaupt sein kann ?
Hi Willa!
Wie feingranular sind denn da die Messwerte?Zitat:
Zitat von Willa
Deine Aussage wird sicher stimmen, will ich nicht bestreiten, ich möchte nur ein Gefühl für die Grenzen haben.
Wenn ich eine Abweichung von, sagen wir, einem Zähler habe, wirkt sich das dann im Flug noch aus?
Falls ja, kann ich dann per Trimmung am Sender ausgleichen, oder muss ich Glück mit der Abstimmung der Kombination Sender-Empfänger-TriGUIDE haben?
(Ich stelle mir gerade das Horrorszenario vor, dass mit einer bestimmen Zahl der Tri nach hinten kippt, mit einer um 1 größeren Zahl nach vorne. Ich bräuchte also 0,5 als Zwischenwert (wie gesagt, nur ein Szenario!)).
Das Zitat kann ich nicht ohne Weiteres zuordnen, es passt aber prima als Aufhänger zu einer Frage, die ich schon immer mal stellen wollte:Zitat:
Zitat von Willa
Wie erkenne ich, ob ein Regler mit der eingestellten Updaterate noch zurecht kommt oder schon überfahren wird? Hast du da Erfahrungswerte?
Naja, wenn der Copter gut fliegt, dann können die Regler es. Wenn er nicht gut fliegt, dann können es die Regler nicht... Eine andere Methode gibt es da wahrscheinlich nicht, es sei denn man hat die Möglichkeit zeitaufgelöst die Sollwerte und den Ausgang am Regler zu vergleichen.Zitat:
Wie erkenne ich, ob ein Regler mit der eingestellten Updaterate noch zurecht kommt oder schon überfahren wird? Hast du da Erfahrungswerte?
Ein Zähler wirkt sich im Flug wohl kaum aus. Ich denke, das würde nur darüber entscheiden, ob z.B. der Copter mit 1cm/s oder mit 1.1 cm/s wegdriftet. Die Trimmung würde ich nicht nehmen um im Hovermode den Copter auf der Stelle zu halten. Sobald man in den Acro-Mode umschaltet wird die Trimmung als Sollwert interpretiert, und der Copter dreht langsam weg.Zitat:
Wenn ich eine Abweichung von, sagen wir, einem Zähler habe, wirkt sich das dann im Flug noch aus?
Falls ja, kann ich dann per Trimmung am Sender ausgleichen, oder muss ich Glück mit der Abstimmung der Kombination Sender-Empfänger-TriGUIDE haben?
Hi,
ich nutze ja bekanntlich die SS Regler von Hobbyking, Sven aus W hat mir die ja Explizit empfohlen und einige der User auf Willa's Userbase Seite nutzen die ja auch, nun sagte Willa ja vor ein paar Wochen, dass er mit denen vorsichtig wäre, da man nich weiss was man kriegt. Ich werde jetzt die Turnigy Plush 25A ausprobieren, die gehen Preislich noch, vielleicht sind die SS ja wirklich nicht geeignet...
Eine andere Frage:
Ich bin ziemlich unzufrieden mit dem Kabel an meinem Imu, ich würde es gerne gegen ein IDE Kabel aus dem PC ersetzen, dazu brauche ich aber einen 8-Poligen Stecker für den TRIguide im gleichen Design wie die Mainboard IDE Stecker, hat jemand eine Ahnung wie die heissen? Ich würd gerne bei Reichelt bestellen.
Noch eine:
Mein Servo liegt zur Zeit im Center und ist mit einer Achse zum Heck verbunden, ich habe hier im Thread was von einer Begrenzung auf 30° gelesen, wie wirkt sich das jetzt für mich aus? Ihr macht das ja alles über die Hebel, also ein Vollausschlag im servo entspricht dann ja 30° am Motor,
ist das jetzt bei mir ein Problem oder schafft die Regelung das selber?
Gruß
Nils
Ich theoretisiere mal ein wenig... :)Zitat:
Zitat von Willa
Mit 417 Hz (für Mitleser: das ist die schnellste Updaterate, die deine I2C-PWM-Umsetzer ausgeben können) und Vollgas, das entspricht 2 ms Pulsbreite des PWM-Signals bei 100% am Sender, haben wir noch schmale 400 µs Pause, bevor der nächste Puls kommt.
Erhöhe ich am Sender die Max-Werte auf 150% (um den Wert 37 für Vollgas bzw. -37 für Stopp zu erhalten) würde ich mit 3 ms für Maximum (wegen 150%-Einstellung im Sender) gar keine Pause mehr haben, der ESC ginge also aus, weil er nichts mehr zum Messen findet.
Ich sehe schon, ich komme um eine echte Messung nicht herum... ;)
Die nachfolgenden Messungen habe ich am Kanal-Ausgang des Empfängers durchgeführt, der Sender ist ein MC-15 von Graupner:
Minmum-Throttle bei 150%-Einstellung am Sender ergibt einen Puls von 0,92 ms. Maximum liegt bei 2,09 ms. Der Abstand zwischen zwei Pulsen beträgt hier 22,04 ms, also ~45 Hz.
Das ist die normale Updaterate für Servos und ESCs mit PWM-Eingang.
Bei 100%-Einstellung am Sender sind die Zeiten zum Vergleich: Min 1,14 ms und Max 1,89 ms.
Worauf sich also die %-Angaben im Menü des Senders beziehen kann ich so nicht sagen, wir brauchen aber für die ESCs auch bei 150%-Einstellung erst mal keine Angst zu haben.
... Ah, jetzt! Nach Hirn komplett einschalten kommt mir doch eine Idee :).
Die Prozente beziehen sich auf den Weg zwischen Min und Max. Bei 100% haben wir da 750 µs (1,89 ms - 1,14 ms), bei 150% sind es gemessen 1,17 ms und gerechnet 1,125 ms. Ähnlich genug.
Die 150% habe ich am Sender einstellen müssen, damit die Timingbedingungen für Throttle und Schalter der TriGUIDE erfüllt werden. Mit kleinerer Einstellung (130%) blieb die TriGUIDE im Anlauf hängen und blinkte mit den beiden äußeren LEDs.
Jetzt Messungen am I2C-Konverter:
Aus dem I2C-Konverter kommt bei gleichen Einstellungen (150%) für Min 1,16 ms und Max 1,95 ms raus.
Da ich die Konverter auf 292 Hz Updaterate gestellt habe bekomme ich an deren Ausgang eine gemessene Updaterate von ... 167 Hz, alle 5,96 ms kommt ein Impuls. :?:
Warum der Wert so weit abseits liegt, kann ich nicht sagen. Möglicher Weise habe ich die Fuses falsch gesetzt? Das lässt sich kontrollieren.
Jetzt ist gerade der Akku meines Senders leer geworden, ich schlicke den Post mal los. Den offenen Punkt zu der Updaterate der Konverter lliefere ich nach.
Hi Nils,
Du meinst die alten grauen Flachbandkabel? Ich fürchte, die sind mindestens suboptimal für die analogen Signale des IMU-Würfels.Zitat:
Zitat von jevermeister
Die zugehörigen Stecker (die für auf die Platine) heißen Wannenstecker.
Wahrscheinlich willst du dann "Pfostenbuchsen" mit Schneidklemmkontakten, um die Flachbandkabel unkompliziert anschlagen zu können.
Der vordergründige Nachteil dieser Lösung: Die Stecker/Buchsen gibt´s bei Reichelt mit 6 und mit 10 Pins.
Am Besten verwendest du zwischen IMU-Würfel und TriGUIDE verdrillte Einzeladern. Ich verwende als Buchse am Kabel einen passenden Abschnitt der Buchsenleiste "BL 2X36G 2,54 :: 2x36pol. Buchsenleiste, gerade, RM 2,54". Einfach zum Kürzen z.B. mit einem Teppichmesser (auf einer Holzunterlage) am nächsten Kontaktschacht (also für 8 Kontakte am 5. Kontakt) abschneiden und die Kante glätten, geht prima.
Das passende Gegenstück auf der Platine sind Pfostenleisten des Typs "SL 2X36G 2,54 :: 2x36pol.-Stiftleiste, gerade, RM 2,54", ebenfalls zum Abknipsen für die passende Stiftzahl. (Jeweils Reichelt Bestellnummern).
Dein Servo-Problem ist keins, denn für Servos wird immer die Drehgeschwindigkeit in Bruchteilen von Sekunden für 60 Grad angegeben, das dürfte bei fast allen marktgängigen Servos der Drehwinkel von Anschlag bis Anschlag sein, eher etwas weniger, die 30 Grad nach beiden Seiten bekommst du also auch bei einer 1:1 Übersetzung per Hebel oder eben mit deinem direkten Anschluss.
Und die 30 Grad sind eher als Optimum zu lesen, mehr schadet nicht, das gleicht die Regelung aus indem sie weniger weit auslenkt. Weniger könnte problematisch werden, im Zweifelsfall wird der Tri ein wenig weniger agil, also träger, reagieren. Letzteres nehme ich mal wohlwollend an bis einer der Fachleute das Gegenteil behauptet.
@Harald:
ich rechne grad nochmal nach und stelle die Ergebnisse gleich rein. Nur so viel schon mal: Die Pause zwischen zwei high-pulsen ist fix. D.h. mit dem Einstellen der Jumper gibst du die Pause vor. Außerdem arbeiten die Konverter komplett unabhängig vom Sender. Als Eingang bekommen die per I²C einen wert zwischen 0 und 255. Dieser Wert wird umgerechnet zu einer Pulsbreite zwischen 0.99ms und 2.01 ms.
Im Moment sieht es fast so aus als wäre ein Tippfehler im Quellcode der Konverter aufgrund eines fehlenden Oszis blieb der vielleicht unbemerkt... Da du ja ein Oszi zu haben scheinst, kannst du mal bitte messen was der Konverter liefert bei den verschiedenen Rate Einstellungen?
Wegen dem Servo: Ich würde nicht mehr als 30° nehmen, denn die Auflösung eines Servos ist stark begrenzt, d.h. man verliert einiges an Präzision wenn man mehr als 30° zulässt. Die 30° sind aber auch nur geschätzt, der im Flug wirklich notwendige Maximalausschlag ist mir unbekannt.
Hi Willa,
aha, das heißt, die Updaterate des Konverters ist variabel. Wow. Sollte aber unproblematisch für die ESCs sein.
Ohne in die Programmierung allgemein oder in die der ESCs im Speziellen allzu weit eingedrungen zu sein, könnte ich mir vorstellen, dass die auf eine Flanke am Eingang warten (per Interrupt) und dann mit der Messerei der Pulslänge anfangen.
Danach kommt es nur noch darauf an, alle Sicherheits- und sonstige Abfragen und Berechnungen schnell genug abzuwickeln, um die nächste Pulsflanke nicht zu verpassen.
Wenn das zutrifft, müsste sich ein "Überfahren" des ESC durch zu schnelle Pulsfolge als Skipping eines Pulses auswirken, die Updaterate halbiert sich also. Funktionieren müsste ein "zu langsamer" ESC also trotzdem, nur nicht optimal.
Basierend auf den gleichen Überlegungen müsste ein ESC also auch die variable Pulsfolge verdauen.
Aber wie geschrieben, das ist nur, wie ich es machen würde, könnte ich das :)
Die Messungen liefere ich, wenn mein Senderakku wieder voll ist.