Problem althold, attitude hold, heading hold

Hallo Holger,

also ein GPS-Glitch ist ein plötzliches „Weghüpfen“ des GPS-Signals. Kann z.B. durch Multipathing ausgelöst werden. Das ist die Reflexion des Signals an Gebäuden, Bäumen, Berghängen usw. Wenn das GPS-Signal von so einer Reflexion empfangen wird, hat es ja einen längeren Weg zurückgelegt und der GPS-Empfänger denkt, er wäre tatsächlich weiter vom Satelliten entfernt, als er es eigentlich ist. Das heißt, Du hast mit einem Mal eine Fehleinschätzung der Position, was der Heli natürlich auszusteuern versucht.

Ja genau. Ich meinte vor allem die seitliche Abweichung. In Bodennähe kann der Heli dann mit den Blättern Bodenkontakt bekommen oder einfach umkippen, weil er mit den Kufen / dem Fahrwerk irgendwo am Boden hängen bleibt.

Hmmm, seltsam. Das war doch bisher nicht der Fall? Klingt für mich nach einer falschen Einstellung von H_Col_MID. Oder versucht der Heli tatsächlich zu steigen? Das kannst Du in den Logs (Dataflash) erkennen, wenn Du Dir die target altitude vs. actual altitude anschaust. Die findest Du unter CTUN als DAlt (desired alt) und Alt. Dann siehst Du ja, was er machen will.

Viele Grüße

Felix

Hallo Felix, prost neujahr,
jo - verstanden.

Ich hatte das Problem auch schon im im 4.0 thread beschchrieben und “unser” Bill hatte geantwortet.

Allerdings glaube ich, den Fehler gefunden zu haben: Du hast Recht, mein H_COL_MID war viel zu hoch, fast wie der obere _MAX - Wert.
Das hatte aber in 3.6 nicht gestört, es funktionierte ja gut. Und ich habe ja bei 4.0 keine params verändert.

Habe ich jetzt auf “Mitte” eingestellt. jetzt bleibt / springen die TS zur eingestellten Mitte / Schwebeposition.

Allerdings kann ich sie am Boden nicht hoch / runterregeln. das ging in 3.6.

Denn das System nimmt (am boden) in Disarmed, armed und bei Motorlauf den POSHOLD klaglos an (Buzzer, MP positiv, keine Fehlermeldungen).

Bin aber noch nicht wieder geflogen.

Viele Grüße Holger

Hallo Holger,

ja, klingt so, als hättest Du das Problem jetzt vollständig behoben. Warum das in 4.0 anders ist als in 3.6 kann ich Dir nicht sagen. Habe selber auch noch nicht die 4.0 drauf und werde das vermutlich auch noch nicht in nächster Zeit machen. Ich fliege nicht mit der Standard-Firmware…

Wenn MP den Mode-Wechsel ohne Fehlermeldungen annimmt würde ich das aber einfach mal in der Luft ausprobieren. Ich denke mal, dass dann auch die Höhenvorgabe funktionieren wird. Wenn nicht, sehen wir ja in den Logs, was das Problem war.

Viele Grüße

Felix

hallo Felix,
laut Mitteilung von Bill im 4.0 thread hat sich in 4.0 einiges geändert, insbesondere ist H_COL_MID jetzt ganz wichtig und muss extrem richtig eingestellt werden. mal schauen.
Vielleicht funktioniert es auch, werde es natürlich probieren.
sollte letzten Endes das nicht gehen, gehe ich auch zurück auf 3.6.
Werde berichten.

Es steigt die Wahrscheinlichkeit, dass ich zur Rotor-live gehe.

viele Grüße Holger

Hallo Felix,
mal ein kleiner Zwiwschenbericht. Die Diskussion mit Bill über 4.0 und Althold hast Du ggf. verfolgt.

Habe meinen Protos 500 mit einem neuen PIX 4 mini ausgerüstet. Bei 4.0 habe ich gleich gesehen, dass Althold da auch nicht geht. Da er ja frisch jungfräulich aufgesetzt ist, gehe ich zunächst von einen bug im PIX i.V.m. der 4.0 aus. Bill möchte ja einen log haben - demnächst.

Betreibe den Protos also erstmal mit 3.6. Habe das Einfliegen fast fertig, geht alles sehr gut einschl. Althold, RTL usw. Wenn fertig, werde ich mit 4.0 den log machen.

Allerdings auch hier: der Kompass zeigt in der Karte eine Abweichung von rund 10 Grad, die ich durch nichts wegkriege. Allerdings scheint das bei Poshold usw. nicht zu stören. Habe ihn sogar “streng” kalibriert.
Egal, ob Deklination automatisch oder per Hand. Allerdings laut Internetseite hätte ich bei mir 3 Grad 6 Minuten, automatisch kommt er immer auf 2 Grad 55 Minuten - ist in der Praxis aber ja nur sehr kleiner Unterschied.

Und noch eine Sache: Er hält die Richtung sehr gut, aber die Heck-Servo-Geschwindigkeit ist relativ langsam. Das Heckservo folgt nicht der Knüppelgeschwindigkeit, ist viel langsamer, und “Einrasten” kennt er überhaupt nicht. 3D wäre so überhaupt nicht möglich. Wo könnte man da noch stellen?
Die TS-Geschwindigkeit reicht mir zwar, wäre aber auch nicht 3D-fähig.

Und nochmal zum Kompass: Habe noch einen MATEK 405 Controller, nur auf einer Platine mit dem GPS/Kreisel - nicht verbaut. Der macht Althold bei 4.0 auch nicht.
Und der Kompass (ohne störenden Heli drumrum) hat noch eine höhere Abweichung.

Viele Grüße Holger

Hallo Holger,

gut, dass Du es sagst. Ich hatte die letzten Tage gar keine Zeit, wieder in den Thred zu schauen…

Wie hoch sind denn Deine Kalibrierwerte? Wenn die zu hoch sind, deutet das auf zu viele ferromagnetische Dinge in der Umgebung Deines Kompasses hin. Vielleicht bringt ihn das durcheinander…

Dass das Heckservo am Boden so langsam läuft, ist tatsächlich in Ordnung. Ich musste mich auch erst an den Anblick gewöhnen. Das heißt aber nicht, dass sich der Heli in der Luft schlecht verhalten oder nicht einrasten würde. Du steuerst mit dem Knüppel ja auch nicht direkt das Heckservo, sondern genau genommen gibst Du eine Drehrate vor mit der sich der Ghost wegdreht. Wenn der Heli nicht knackig genug reagiert, liegt das am Tuning. Schau, dass der P-Wert hoch genug ist. Und wenn der Heli träge wie in Honig reagiert, ist Dein D-Wert zu groß. Wenn er allgemein zu langsam reagiert, kannst Du ACRO_YAW_P erhöhen.

Ich denke, dass das auch eher am Tuning liegt. Alternativ kannst Du RC_SPEED bis zur maximalen Frequenz von Deinen Servos anpassen. Habe bei mir aber nicht den Eindruck gewonnen, dass das einen spürbaren Unterschied macht…

Viele Grüße

Felix

Hallo Felix,
Beim Tuning habe ich eigentlich schon ziemlich hin- und herprobiert. höheres P führt schnell zum Schwingen.
Habe aber glaube ich den Fehler gefunden. mein ATC_ACCEL_MAX für yaw war völlig falsch. jetzt mit der “schnellen” Einstellung geht das Heckservo deutlich schneller als vorher (zunächst auf dem Tisch).

Kompass: An der Kalibrierung kann es eigentlich nicht liegen. Die Kreisel liegen ja beim Tandem und Single völlig woanders. Beim Protos habe ich es hinten auf dem Heckrohr - mehr geht ja nicht; und wie gesagt sogar “streng” ohne Problem kalibriert. Interessant ist ja, dass die Abweichung bei beiden Helis nahezu gleich ist.
Und wie gesagt, er hat bei Poshold offenbar keine Probleme.

Weitere Frage: RTL macht er ja super. könnte man irgendwo einstellen, dass er nicht von oben senkrecht landet sondern wie in “echt” auch mit Flugweg schräge nach unten (Landeanflug) landet?

Gruß Holger

Hallo Holger,

ich habe gerade im 4.0 Thread gesehen, dass Du noch immer den Gaskanal falsch verwendest und nur als Passthrough durch den FC schickst. Das kann viele Probleme verursachen. Ich würde Dir daher DRINGEND empfehlen, das wie in der Anleitung beschrieben zu machen und am besten H_RSC_MODE = 2 (Setpoint) zu verwenden!

Solange Du noch kein sauberes Grundsetup entsprechend der Anleitung hast, macht es absolut keinen Sinn, sich um Fragen mit den automatischen Flugmodi zu kümmern! Dann kann das nicht funktionieren. Du ersparst Dir allgemein sehr viel Ärger, wenn Du Dich ganz genau an die Setup-Vorgaben hältst. Und Bill und mir auch. Wir können froh sein, einen Experten wie Bill hier im Forum zu haben. Aber er hat sicher auch besseres mit seiner Zeit anzufangen, als Probleme zu lösen, die aus einem bewussten Ignorieren der Anleitung resultieren. Du wirst feststellen: Wenn Du Dich exakt an die Vorgaben hältst, wird der Großteil Deiner Probleme ganz von alleine verschwinden.

Siehe oben. Der Defaultwert hätte es schon getan. Verändere einen Parameter nur dann, wenn Du weißt, dass es wirklich sein muss und dass Du alles richtig machst. Sonst handelst Du Dir damit nur noch mehr Probleme ein. Und für uns ist es dann auch sehr schwer, zu erkennen, wo der Fehler eigentlich liegt.

RTL soll Deinen Hubschrauber von einem beliebigen Punkt weit draußen sicher wieder zu Dir zurück bringen. Wenn Du von dort aus einen Sinkflug einleiten würdest, könnten dort doch Bäume, Häuser oder andere Hindernisse dazwischen sein. Dann würde der Heli dagegen fliegen. Deshalb ist das gar nicht erwünscht. Wenn Du einen gezielten Landeanflug machen willst, kannst Du das mit dem Auto-Modus tun. Plane eine Flugroute und lasse ihn vor der Landung einfach wie gewünscht absinken.

Das alles macht aber keinerlei Sinn, bevor Du kein sauberes Grundsetup hast. Solange der Heli noch nicht einmal das Heck sauber halten kann, keinen funktionierenden Kompass hat und offenbar auch noch ein paar andere grundsätzliche Einstellungen falsch sind, kann das nichts werden. Ich würde Dir außerdem empfehlen, Dich dann erstmal ausführlich dem Tuning zu widmen. Bevor das nicht perfekt ist, sind alle automatischen Modi ein Glücksspiel…

Viele Grüße

Felix

1 Like

Hallo Felix,
ja, ich möchte Euch bei Eurer Hilfe ja auch nicht verärgern.
Deshalb bin ich gerade dabei, ALLES (nochmal) nach Anleitung und Hinweisen zu machen.

Nochmal vorweg: in 3.6.12 ging alles, er flog super in allen modi incl. RTL. Tuning war sehr gut.

Nun also wieder 4.0.1
Im Wiki steht ja, dass man nach dem upgrade normalerweise keine parameter ändern muss - gut.

habe auf CH8 nun HELIRSC genommen. Setpoint steht auf 70%. Gassignal kommt mit 100% vom Sender.
Arming chek auf 1 (= alle).

Beim Arming kommt: “PreArm: motor interlock not enabled” (???)

ich kann ohne Protest in “althold” schalten. Aber beim “anschalten” (auch bei acro / stabi) bekommt der Motor kein Signal über HeliRSC (rotorblätter natürlich ab), motor läuft nicht an.

Und ich kann in “althold” die TS nicht auf/ab bewegen, was vorher auch immer so war und darauf hindeutet, dass althold jetzt auch wieder nicht gehen würde. (bei 3.6 geht das)

Ich wüsste nicht, was ich jetzt noch falsch gemacht haben sollte.

In den Meldungen für 4.0 steht auch, dass es auch mit “RCpassthrough” gehen sollte.
Scheint auch zu sein, denn mein Freund ist aktuell auch auf “rcpassthrough” gegangen, und bei ihm geht althold in 4.0 wie vorher auch weiterhin.

Da ich ja nun den 2. miniPix frisch angeschlossen habe und es genau wie beim ersten nicht geht, muss da ja doch noch was anderes sein. Verdacht war ja Pix-Konflikt mit 4.0?
Mein Freund hat ja Matek / Kakute und hatte auch schon mal fehl/nicht-funktionen nach upgrade auf neue FW.

Hast Du jetzt noch Ideen?

Viele Grüße Holger

Please send me a log of this behavior. You will have to set the LOG_DISARMED parameter to 1 so it will log data while disarmed. Do you have a throttle hold switch connected to channel 8 on your RC transmitter? If not, then you need to. when you first power up the flight controller, the throttle hold switch should be low (PWM = min value). After you arm the system, then you would switch the throttle hold switch should be high (PWM=max value). If you are not armed and your throttle hold switch is high then you will receive the message “Motor interlock not enabled” This warning is basically telling you that your throttle hold switch is high meaning that you are trying to apply throttle to the engine before you have armed the system. Hopefully this makes sense.

Regards,
Bill

Holger,
Looking at your last param file you posted, it looks like you have not assigned an RC channel as Motor Interlock (RCn_OPTION = 32). If you are controlling the throttle with RC channel 8 then you would set RC8_OPTION to 32. Also is your ESC connected to the channel 8 output port of your pixhawk. I just want to make sure that you don’t have it connected to the RC receiver. The only thing connected to the RC Receiver is the pixhawk. All servos and ESCs are connected to the pixhawk.

I’ve modified the wiki on connections and calibrations here. Please read if you haven’t already and see if this helps clarify (or not) the motor interlock feature.

Hello Bill,
that was obviously it!

But I had also connected the ESC to Kanal8 from the PIX early on since your and Felix Info.
Now I have also set the Kanal8 to 32 (motor interlock) and it seems to be working!

I didn’t have that at 3.6. I didn’t know that either. Now i read the “new” wiki".

Anyway, I can now move the swashplate at ALTHOLD and it should work. When the weather is better I can fly and of course I will report.

So thanks again to you and Felix!

Holger

Hallo Holger,

vielen Dank, dass Du das Setup noch einmal sauber gemacht hast. Ich denke das wird viele Probleme lösen. Es ist wichtig, dass der FC ein gültiges Gassignal bekommt, damit er weiß, wann der Rotor tatsächlich dreht. Davon hängen viele Dinge ab, beispielsweise das „Freilassen“ des Ghosts. Solange der Controller nicht weiß, dass der Motor hochgefahren hat, ist also das Verhalten des Hubschraubers völlig anders.

Ich bin gespannt auf Deinen Bericht.

Viele Grüße

Felix

Hallo Felix,
das war ja das verwirrende. in 3.6 brauchte er (für allthold) auch ein gültiges Gassignal, aber dann ging es ja ohne (zusätzlichen) Motor interlock.

Kannst Du noch mal erklären, warum man die “Sicherheitsstufen” nicht zusammenlegen- / fassen könnte?

Ich muss jetzt 1. Hardware Sicherheitsschalter 2.armen und 3. den Interlock (nun mit gas, aber ja auch mit anderem Kanal möglich).

Den Hardwareschalter kann ich ja deaktivieren, hatte ich auch schon mal. Aber arming und interlock könnte man doch eigentlich (vom Sinn her) zusammenlegen?
Oder arming und interlock mit auf den Hardwareschalter - ginge das?

Und wenn man schon den interlock auf jeden Kanal nehmen kann, würde ich ihn vielleicht auf Kanal3 nehmen, um den Motor nur anschalten zu können, wenn pitch unten ist.

Im wiki scheint da auch eine Anleitung zu sein, verstehe ich aber nicht.

Aber Hauptsache, es scheint nun zu gehen. Das Tuning jedenfalls war schon sehr gut.

Gruß Holger

Wonderful News!!! Sorry that I didn’t get the wiki in sooner. I have been meaning to put in a section on motor interlock for quite some time. I know users have a hard time with the motor interlock concept.

In 3.6, You didn’t need to specify motor interlock on an RC input because it was directly tied to channel 8. That was one of the changes in 4.0

Hallo Felix,
nun wollte ich auch den Tandem wieder auf 4.0 nehmen.
FW laden geht, kriege aber am PC keine Verbindung zum MP mehr. sowohl in 4.0.0 , 4.0.1 und die neue 4.0.2
auch am Laptop nicht mehr.

wenn zurückgehe auf 3.6, kriege ich wieder Verbindung.

gibts da eine Lösung?

Gruß Holger

Holger,
Make sure you choose the correct com port. I think it may be due to going from NuttX (3.6 OS) to Chibios(4.0 OS). I know that I have to select a different com port when I upgraded to 4.0. The com port is selected from the pull down box next to the Connect/disconnect button in the upper right corner of the mission planner window.

Hallo Holger,

ich glaube Bill hat Recht. Das könnte tatsächlich am COM-Port liegen.

Zu Deiner Frage, warum man die „Sicherheitsstufen“ nicht zusammenfassen kann: Eigentlich hast Du das ja schon getan. Den Hardwareschalter hast Du deaktiviert, Interlock hast Du auf den Gaskanal gelegt und das einzige was bleibt, ist dann noch das Armen. Eine Sicherheitsfunktion ist ja auch mindestens nötig. Die Sicherheitsfunktionen haben aber auch alle einzeln ihre Berechtigung und ihren Sinn. Beispielsweise kannst Du mit dem Sicherheitsschalter ja auch verhindern, dass sich die Servos bewegen. Ich habe die Funktion aktiviert gelassen. Oft muss man ja auch nur in der Software Einstellungen ändern und will gar nicht, dass die Servos mitlaufen. Was den Interlock betrifft: In Deinem Sender hast Du ja wahrscheinlich auch einen Gaslimiter. Das ist doch genau das Gleiche…

Ich verstehe aber auch nicht, warum Du Dir Sorgen um zu viel Sicherheit machst. Wenn man einen 20 kg Hubschrauber baut, sollte doch jede zusätzliche Sicherheitsfunktion willkommen sein. Da kann schnell etwas schief gehen. Bevor mir so ein Hubschrauber im Zimmer versehentlich mit Vollgas anläuft, ist es mir lieber, ein Mal auf den Sicherheitsschalter drücken zu müssen. So anstrengend ist das ja auch nicht.

Viele Grüße

Felix

Hallo Felix und Bill,
das mit den wechselnden Comports weiß ich, musste ich bei den diversen Wechseln ja immer beachten, daran liegt es nicht. Die Comports laufen laut Gerätemanager auch immer einwandfrei.
Bei meinem neuen, 2. PIX hatte ich zunächst das gleiche Problem. Zu Anfang gleich 4.0 raufgespielt, ging nicht , kein Kontakt. Dann 3.6 versucht, da ging alles. Dann wieder 4.0 raufgespilet, nun ging auch das.

Das habe ich jetzt auch mehrfach versucht, das gleiche: 4.0 = keine Verbindung zum MP, bei 3.6 = alles problemlos. Da er 3.6 problemlos annimt, könnte da in der FW 4.0 speziell bei dem PIX etwas sein?
Es ist auch so, dass garnicht erst die Fehlermeldung “keinKontakt” kommt, sondern es läuft die Eieruhr, das Programm hängt sich auf.

Zu den Sicherheitsstufen: bitte nicht falsch verstehen. die höchste Sicherheit ist natürlich wünschenswert. Ich dachte nur an Vereinfachung, indem man die “drei” vielleicht in einer zusammenfassen würde.
Aber natürlich geht es auch so. ist eben für “Normalflieger” noch ungewohnt.

Viele Grüße Holger

Hallo Felix und Bill,
ich habe es jetzt geschafft, 4.0.2 raufzunehmen.
Aber: da muss ein bug in der FW sein.

Habe zunächst MP auf neueste Beta-Version upgedatet - keine Änderung (3.6 - 4.0 hin und her)

dann QGroundcontrol (neues update) (weil ich da im Forum gelesen hatte: update 4.0 mit MP ging bei einem nicht ).

Nun mit QG 4.0 (die normale) rauf - gleiches Bild: QG bekam keinen Kontakt zum PIX.
dann mit QG die mögliche “einfachere” version aufgespielt. Ging, er bekam Kontakt.

MP bekam nun auch Kontakt, aber da sind ja nur ganz wenige Daten / Parameter.

Nun mit MP auf 4.0.2 upgedatet. Nun geht es - MP hat jetzt Kontakt.

Die erstellten Comports heißen bei den verschiedenen Versionen auch immer anders. Zu Anfang “CHBIOS”(o.ä.). dann zwischendurch anders, jetz am Schluß wieder “CHIBIOS”.

ist doch sicher nicht in Ordnung - oder?

Viele Grüße Holger