Willas Shrediquette Tricopter / Quadrocopter / Hexacopter

[deHarry]

Wie erkenne ich, ob ein Regler mit der eingestellten Updaterate noch zurecht kommt ...

Naja, wenn der Copter gut fliegt, dann können die Regler es.

Ich theoretisiere mal ein wenig...

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.

[deHarry]

Hi Nils,

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.

Du meinst die alten grauen Flachbandkabel? Ich fürchte, die sind mindestens suboptimal für die analogen Signale des IMU-Würfels.

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.

[Willa]

@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.

[deHarry]

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.

[Willa]

Basierend auf den gleichen Überlegungen müsste ein ESC also auch die variable Pulsfolge verdauen.

Ja, das war auch meine Idee damals.
Es scheint sich tatsächlich von Anfang an ein Tippfehler eingeschlichen zu haben... Demnach fliege ich seit Anfang an nicht mit den erwarteten 417 Hz, sondern nur mit 286.5 Hz...
Ich werde das jetzt überprüfen und die I²C Konverter meines DLXm neu flashen (die Nacht ist ja noch jung...). Im Anhang meine Berechnungsgrundlage.

[jevermeister]

Hallo ihr zwei,

was heisst denn das jetzt in der Praxis für das Flugverhalten?
Bei meinen Flugversuchen stelle ich ja dieses Regelmäßige Zucken fest und dann geht ja hin und wieder mal ein Motor in Vollgasmodus, kan das eine Folge daraus sein?

Warum sollten die Kabel schlecht sein? Wegen der fehlenden Schirmung?

Momentan habe ich sie verdrillt, aber das ist total unflexibel und dadurch drückt das kabel auf den IMU

Gruß
Nils

[Willa]

kan das eine Folge daraus sein?

Nein. Deine Regler gehen aus anderen Gründen einfach nicht.

Achso, ich habe gar nicht gesagt wo der Tippfehler war: Ich habe einfach die Zahlen 63545 und 64535 vertauscht...

[jevermeister]

@Willa: Vestehe ich das Richtig?
Wenn Du die Converter jetzt neu flasht und das tatsächlich ein Fehler war,
dann regelt der Shreddi noch schneller als sowieso schon?

Gruselig....

[Willa]

Hi Nils,
also, der Hauptcontroller läuft im Acro Modus mit ca. 400 Hz, im Hovermodus mit ca. 330 Hz. Mit dieser Geschwindigkeit gibt der Controller neue Sollwerte an die I²C Konverter. Wenn die nur mit 286.5 Hz laufen, dann läuft die gesamte Regelung auch nur mit dieser Frequenz. Ich habe meine Konverter nun auf 491.4 Hz eingestellt und probiere gleich mal zu fliegen. Außerdem habe ich meine DLXm grad gestern auf Hardware I²C umgestellt, der Hauptcontroller läuft nun mit 613Hz im Acromodus. Ob das in kombination nun einen merklichen Unterschied bringt oder nicht kann ich gar nicht sagen. Immerhin sind die Motoren wohl das trägste Glied im Regelkreis, keine Ahnung ob eine schnellere Ansteuerung überhaupt schneller in Lufkträfte umgesetzt werden kann.

[deHarry]

Hi Willa,

also meine Messungen mit dem Oszi ergaben Folgendes:

Werte jeweils im Leerlauf, Schalter am Sender auf Motors off (das macht einen Unterschied. Mit Schalter auf Hover oder Acro werden die Pausen etwas länger. Aber unwesentlich).

Rate1 Rate2 (Jumpers)
open open -> 18,5 ms Pause -> 51 Hz
open closed -> 1,9 ms -> 336 Hz
closed open -> 4,8 ms -> 171 Hz
closed closed -> 1,8 ms -> 335 Hz

Beachtenswert: open/closed und closed/closed sind fast identisch. Passt das zu deiner Programmierung (die noch mit dem Fehler)?