STorM32 BGC: 3-Achsen STM32 Brushless Gimbal Controller
- Themenstarter OlliW
- Beginndatum
@Phyton:
1.: klingt gar nicht gut
was heisst das genau es sind 2 Imus verbaut?
was passiert wenn du eine zweite extra Imu an Port I2C#2 anschliesst?
2.: bist du dir sicher dass das ein HC06, und nicht evtl ein HC05 oder so, ist?
was sagt denn das GUI-Tool?
@buckker:
doch ... warum sind die Videos immer doppelt verlinkt?
(und wieder ein sehr nettes Video!!)
1.: klingt gar nicht gut
was heisst das genau es sind 2 Imus verbaut?
was passiert wenn du eine zweite extra Imu an Port I2C#2 anschliesst?
2.: bist du dir sicher dass das ein HC06, und nicht evtl ein HC05 oder so, ist?
was sagt denn das GUI-Tool?
@buckker:
doch ... warum sind die Videos immer doppelt verlinkt?
(und wieder ein sehr nettes Video!!)
Zuletzt bearbeitet:
Hey,
Das Storm32 selbst hat ja einen IMU direkt mit auf dem Board verbaut, ein weiterer Sensor sitzt vorne unter der Halterung, auf der die Kamera sitzt, das zweite IMU ist am I2C#2 Port angeschlossen, funktioniert aber nicht, bzw reagiert nicht auf die Eingaben. Wenn ich die Kalibrierung starte, dann bekomme ich "IMU1 is not healthy".
Das BT-Modul ist ein HC06, wir haben exakt das Modul aus dem Wiki/Tutorial bestellt
Gruß,
André
Das Storm32 selbst hat ja einen IMU direkt mit auf dem Board verbaut, ein weiterer Sensor sitzt vorne unter der Halterung, auf der die Kamera sitzt, das zweite IMU ist am I2C#2 Port angeschlossen, funktioniert aber nicht, bzw reagiert nicht auf die Eingaben. Wenn ich die Kalibrierung starte, dann bekomme ich "IMU1 is not healthy".
Das BT-Modul ist ein HC06, wir haben exakt das Modul aus dem Wiki/Tutorial bestellt
Gruß,
André
sei mir nicht böse, aber es ist wichtig gute Infos zu geben ... wir können uns ja nur und ausschliesslich auf das beziehen was du uns sagst
nun klingt es so, dass die IMU1 nicht healthy is aber auf Bewegung reagiert, eine zweite IMU am I2C#2 zwar healthy ist aber auf Bewegung nicht reagiert, und die on-board IMU funktioniert, oder doch nicht ???
sorry, da werde ich nicht schlau draus
gehe schrittweise vor
keine IMUs angeschlossen -> was meldet die GUI beim connecten, und die Statuszeile, kannst du Bewegung im DataDispaly sehen
eine IMU and I2C angeschlossen -> was meldet die GUI beim connecten, und die Statuszeile, kannst du Bewegung im DataDispaly sehen
die andere IMU an I2C angeschlossen -> was meldet die GUI beim connecten, und die Statuszeile, kannst du Bewegung im DataDispaly sehen
die erste IMU an I2C#2 angeschlossen -> was meldet die GUI beim connecten, und die Statuszeile, kannst du Bewegung im DataDispaly sehen
die andere IMU an I2C#2 angeschlossen -> was meldet die GUI beim connecten, und die Statuszeile, kannst du Bewegung im DataDispaly sehen
eine IMU an I2C und die andere an I2C#2 angeschlossen -> was meldet die GUI beim connecten, und die Statuszeile, kannst du Bewegung im DataDispaly sehen
:
:
:
nun klingt es so, dass die IMU1 nicht healthy is aber auf Bewegung reagiert, eine zweite IMU am I2C#2 zwar healthy ist aber auf Bewegung nicht reagiert, und die on-board IMU funktioniert, oder doch nicht ???
sorry, da werde ich nicht schlau draus
gehe schrittweise vor
keine IMUs angeschlossen -> was meldet die GUI beim connecten, und die Statuszeile, kannst du Bewegung im DataDispaly sehen
eine IMU and I2C angeschlossen -> was meldet die GUI beim connecten, und die Statuszeile, kannst du Bewegung im DataDispaly sehen
die andere IMU an I2C angeschlossen -> was meldet die GUI beim connecten, und die Statuszeile, kannst du Bewegung im DataDispaly sehen
die erste IMU an I2C#2 angeschlossen -> was meldet die GUI beim connecten, und die Statuszeile, kannst du Bewegung im DataDispaly sehen
die andere IMU an I2C#2 angeschlossen -> was meldet die GUI beim connecten, und die Statuszeile, kannst du Bewegung im DataDispaly sehen
eine IMU an I2C und die andere an I2C#2 angeschlossen -> was meldet die GUI beim connecten, und die Statuszeile, kannst du Bewegung im DataDispaly sehen
:
:
:
Sorry für das ganze durcheinander, ich sitze gerade auf der Arbeit 
Also, in diesem Moment funktioniert KEINER (!) der beiden IMU's. Die on-board IMU wird NICHT erkannt und sie liefert keine Daten. Die zweite IMU funktioniert laut der Kommandozeile, aber sie liefert KEINE Daten. Wenn ich den zweiten IMU von dem I2C#2-Port abziehe, dann sagt er mir immer noch das er eine IMU2 hat, jedoch habe ich diese abgezogen! Der Status meines Gimbals ist nicht normal, sondern level. Der IMU2 hat High-Adress.
Mein Problem ist, dass er sagt, dass ich KEINE onboard-IMU habe, obwohl das ja schwachsinn ist. Ich bekomme KEINE Sensordaten, ich kann nichts kalibrieren. Die Firmware habe ich schon neu geflasht, bringt aber leider nichts. Die LED's sagen mir auch, dass der IMU failed (Laut meiner Kenntnis zu den LED-Codes). Ich hoffe, dass ich das ganze jetzt verständlicher beschreiben konnte
Danke und Gruß,
André
Also, in diesem Moment funktioniert KEINER (!) der beiden IMU's. Die on-board IMU wird NICHT erkannt und sie liefert keine Daten. Die zweite IMU funktioniert laut der Kommandozeile, aber sie liefert KEINE Daten. Wenn ich den zweiten IMU von dem I2C#2-Port abziehe, dann sagt er mir immer noch das er eine IMU2 hat, jedoch habe ich diese abgezogen! Der Status meines Gimbals ist nicht normal, sondern level. Der IMU2 hat High-Adress.
Mein Problem ist, dass er sagt, dass ich KEINE onboard-IMU habe, obwohl das ja schwachsinn ist. Ich bekomme KEINE Sensordaten, ich kann nichts kalibrieren. Die Firmware habe ich schon neu geflasht, bringt aber leider nichts. Die LED's sagen mir auch, dass der IMU failed (Laut meiner Kenntnis zu den LED-Codes). Ich hoffe, dass ich das ganze jetzt verständlicher beschreiben konnte
Danke und Gruß,
André
mir scheint ein grundsätzliches Missverständnis vorzuliegen
1. das STorM32 meldet dir nicht welche IMUs es gibt, sondern welche er für IMU1 und IMU2 nimmt ... ergo, die on-board sieht es nur wenn nichts an I2C#2 angeschlossen ist
2. am I2C#2 darf KEINE Imu mit high-Adresse angeschlossen werden !!!
(deswegen heisst das Ding ja auch nicht AlexMos sondern STorM32, weil es anderes ist als AM)
3. die IMU Detektion geschiet ganz am Anfang nach nem Power uP ... während des Betriebs Imus ein-und-aus-zustöpseln ist nicht
(und führt nur zu kaputter Elektronik)
wie gesagt, evtl etwas systematischer vorgehen
1. das STorM32 meldet dir nicht welche IMUs es gibt, sondern welche er für IMU1 und IMU2 nimmt ... ergo, die on-board sieht es nur wenn nichts an I2C#2 angeschlossen ist
2. am I2C#2 darf KEINE Imu mit high-Adresse angeschlossen werden !!!
(deswegen heisst das Ding ja auch nicht AlexMos sondern STorM32, weil es anderes ist als AM
)3. die IMU Detektion geschiet ganz am Anfang nach nem Power uP ... während des Betriebs Imus ein-und-aus-zustöpseln ist nicht
(und führt nur zu kaputter Elektronik)
wie gesagt, evtl etwas systematischer vorgehen
G
OlliW.... es is echt bitter, aber ich glaube ich muss wieder zurück ins AM Lager wechseln
Ich bekomme es einfach nicht hin. Alle meine Gimbals zeigen den gleichen "Fehler".
nur cam imu -> funktioniert gut, wenn ich stark nach vorne nicke flipt das gimbal aus (um 45° is ja normal)
mit 2ter imu an -> funktioniert extrem gut, leider rastet das gimbal total aus wenn roll mehr als 20° abweicht (das kann man duch sehr niedrige YAW D werte zwar auf fast 60° ausdrehnen, nur sind die D werte dann so gering das das gimbal beim fliegen nicht mehr gut funktioniert)
;( ich komm leider nicht weiter und hab auch keinen weiteren ansatz mehr, hab da super viel zeit reingesteckt. sind leider alle meine 4 gimbals genau gleich. hast du noch irgend eine idee?
ansonsten muss ich echt die bittere pille nehmen und wieder n AM kaufen *kotz*
Ich bekomme es einfach nicht hin. Alle meine Gimbals zeigen den gleichen "Fehler".
nur cam imu -> funktioniert gut, wenn ich stark nach vorne nicke flipt das gimbal aus (um 45° is ja normal)
mit 2ter imu an -> funktioniert extrem gut, leider rastet das gimbal total aus wenn roll mehr als 20° abweicht (das kann man duch sehr niedrige YAW D werte zwar auf fast 60° ausdrehnen, nur sind die D werte dann so gering das das gimbal beim fliegen nicht mehr gut funktioniert)
;( ich komm leider nicht weiter und hab auch keinen weiteren ansatz mehr, hab da super viel zeit reingesteckt. sind leider alle meine 4 gimbals genau gleich. hast du noch irgend eine idee?
ansonsten muss ich echt die bittere pille nehmen und wieder n AM kaufen
*kotz*Grüss dich
Mal ne Frage, hast du mit dem Gyro LPF Wert schon rumgespielt? Standardmässig ist glaub 1.5ms eingestellt. Bei meinem Gimbal bekomm ich so keine vernünftige PID Werte hin. Das Problem ist, dass mit 1.5ms relativ schnell Vibrationen da sind. Den Wert habe ich mittlerweile auf 6ms angehoben. So funktioniert die Sache recht ordentlich.
Den IMU AHRS Wert hat einen ähnlichen Einfluss, allerdings habe ich nicht ganz verstanden für wie sich dieser exakt auswirkt.
Noch was anderes, hast du deine Videos ein wenig auf die Yaw Performance untersucht? Hast du zwischendurch bei Drehungen auch "Hänger" drin? Der Effekt tritt bei mir immer auf wenn ich mit der Kamera ein Objekt ansteuere und um dieses herum fliege (Die Kamera stehts auf das Objekt gerichtet)
Gruss Michael
Mal ne Frage, hast du mit dem Gyro LPF Wert schon rumgespielt? Standardmässig ist glaub 1.5ms eingestellt. Bei meinem Gimbal bekomm ich so keine vernünftige PID Werte hin. Das Problem ist, dass mit 1.5ms relativ schnell Vibrationen da sind. Den Wert habe ich mittlerweile auf 6ms angehoben. So funktioniert die Sache recht ordentlich.
Den IMU AHRS Wert hat einen ähnlichen Einfluss, allerdings habe ich nicht ganz verstanden für wie sich dieser exakt auswirkt.
Noch was anderes, hast du deine Videos ein wenig auf die Yaw Performance untersucht? Hast du zwischendurch bei Drehungen auch "Hänger" drin? Der Effekt tritt bei mir immer auf wenn ich mit der Kamera ein Objekt ansteuere und um dieses herum fliege (Die Kamera stehts auf das Objekt gerichtet)
Gruss Michael
Zuletzt bearbeitet:
@amadeus:
bei der Benutzung einer 2ten Imu ist das leider bekannt dass es bei einigen Gimbals zu Roll-Problemen kommt
IMHO muss das irgendwie an einem Kontruktionsdetail des Gimbals liegen, aber Welches oder Welche ist mir immer noch nicht bekannt
übrigens, ich habe 3 Gimbals mit dem ich meine Tests machen, ein Micro (#808) Gimbal, eines für ne 150g Kamera, und ein Mobius Gimbal. Bei dem Mikro Gimbal habe ich das Problem gar nicht, bei dem 150g Gimbal bekomme ich das gut durch Tunen weg, aber beim Mobius Gimbal bin ich bei Version 11 des Gimbals aber es ist imme rnoch ne Katastrophe
im Sommer-Urlaub hatte ich da sehr intensiv drüber nachgedacht, es hat mich auch weitergebracht, aber es bleibt mysterios
sorry
PS: Das grundsätzliche Problem ist die Yaw-Pitch Kopplung, den Effekt kann man schnell einsehen. Wenn ihr das Gimbal mal in Normalposition haltet und dann etwas Roll gebt, dann kann man schon sehen das sowohl eine Bewegung des Pitch Motors die Kamera pitched aber auch eine Bewegung des Yaw Motors. Deswegen führt das Roll-Problem auch (vornehmlich) zu Oszillationen auf Pitch und Yaw. ABER: Der Effekt ist ja immer da, auch dann wenn keine 2te IMU benutzt wird!!! Aber ohne 2te IMU funktioniert es ja!!! Und das macht die Sache so tricky, man kann bei der 2ten Imu nicht einfach sagen dass ist wegen der Pitch-Yaw Kopplung, denn die gibt es ja 1zu1 auch ohne 2ter IMU. Es ist irgendein komischer Effekt bei der Regelung mit 2ter IMU. Es kann auch kein statischer Effekt sein, denn sonst hätte die Mathematik den entscheidenden Unterschied sofort ausgespukt, und ih hätte das nie so programiert. D.h. das hat etwas mit den höheren Frequenzen zu tun, und das macht es auch tricky. Dazu passt übrigens genau deine Beobachtung das kleines D hilft, denn das wirkt "nur" bei genau den häöheren Frequenzen, und deutet an dass dort der Unterschied liegt.
@buckker:
ich habe das nicht vergessen, ich habe mir das Video 100 mal (naja, 5x) angesehen, und es ist klar was du meinst, aber ich werde trotzdem einfach nicht schlau daraus ... 1. ich kann mir, beim Betrachten des Codes, beim besten Willen nicht vorstellen wie das kommen kann, 2. ich habe versucht das im Garten nachzustellen um zu sehen ob ich das irgendwie reproduzieren kann, aber njente ... und ohne irgendetwas komme ich da nicht weiter
es könnte sein das Daten des Flugs helfen, z.B. mit dem NT Logger
idealerweise würdest du die Vorgehensweiss finden wie du das bei dir im Garten reproduzieren kannst, dann könnte ich das bei mir versuchen, und wenn ich es hinbekomme dann habe ich auch was um das zu analysieren
bei dir hört sich das ja so an als ob das regelmässig wenn nicht gar jedesmal auftritt, d.h. es müsste schon möglich sein eine genaue Versuchsanleitung anzugeben, was man machen muss um es zu beobachten.
Als Beispiel: Vor nicht zu langer Zeit gab es mal Jemanden der so komische ganz kurze aber markante Zucker im Video hatte, war klar im Video zu sehen, aber ja mei, woher soll ich den wissen was das ist, da gab's vorher auch nie nen Bericht. Der Jemand hat dann phantastische Detektiv-Arbeit geleistet, hat rausgefunden dass das Zucken in exakt periodischen Abständen von 43s oder so auftritt, und nur dann wenn man LipoCorrection aktiviert, und schwups war das Problem im Code gefunden und gelöst !!! Das Problem war übrigens extrem subtuil, die Änderung im Code war so das jeder Programierer sagen würde dass darf doch keinen Unterschied mache, machte sie aber (evtl Compiler Problem?). Ist also ein drastisches Beispiel eines Falls wo man sich beim Betrachten des Codes die Augen ausstaren kann.
diese schei... FPVC Auslogzeitgrenze ... die ist doch zum kot...n. grrrr
bei der Benutzung einer 2ten Imu ist das leider bekannt dass es bei einigen Gimbals zu Roll-Problemen kommt
IMHO muss das irgendwie an einem Kontruktionsdetail des Gimbals liegen, aber Welches oder Welche ist mir immer noch nicht bekannt
übrigens, ich habe 3 Gimbals mit dem ich meine Tests machen, ein Micro (#808) Gimbal, eines für ne 150g Kamera, und ein Mobius Gimbal. Bei dem Mikro Gimbal habe ich das Problem gar nicht, bei dem 150g Gimbal bekomme ich das gut durch Tunen weg, aber beim Mobius Gimbal bin ich bei Version 11 des Gimbals aber es ist imme rnoch ne Katastrophe
im Sommer-Urlaub hatte ich da sehr intensiv drüber nachgedacht, es hat mich auch weitergebracht, aber es bleibt mysterios
sorry
PS: Das grundsätzliche Problem ist die Yaw-Pitch Kopplung, den Effekt kann man schnell einsehen. Wenn ihr das Gimbal mal in Normalposition haltet und dann etwas Roll gebt, dann kann man schon sehen das sowohl eine Bewegung des Pitch Motors die Kamera pitched aber auch eine Bewegung des Yaw Motors. Deswegen führt das Roll-Problem auch (vornehmlich) zu Oszillationen auf Pitch und Yaw. ABER: Der Effekt ist ja immer da, auch dann wenn keine 2te IMU benutzt wird!!! Aber ohne 2te IMU funktioniert es ja!!! Und das macht die Sache so tricky, man kann bei der 2ten Imu nicht einfach sagen dass ist wegen der Pitch-Yaw Kopplung, denn die gibt es ja 1zu1 auch ohne 2ter IMU. Es ist irgendein komischer Effekt bei der Regelung mit 2ter IMU. Es kann auch kein statischer Effekt sein, denn sonst hätte die Mathematik den entscheidenden Unterschied sofort ausgespukt, und ih hätte das nie so programiert. D.h. das hat etwas mit den höheren Frequenzen zu tun, und das macht es auch tricky. Dazu passt übrigens genau deine Beobachtung das kleines D hilft, denn das wirkt "nur" bei genau den häöheren Frequenzen, und deutet an dass dort der Unterschied liegt.
@buckker:
ich habe das nicht vergessen, ich habe mir das Video 100 mal (naja, 5x) angesehen, und es ist klar was du meinst, aber ich werde trotzdem einfach nicht schlau daraus ... 1. ich kann mir, beim Betrachten des Codes, beim besten Willen nicht vorstellen wie das kommen kann, 2. ich habe versucht das im Garten nachzustellen um zu sehen ob ich das irgendwie reproduzieren kann, aber njente ... und ohne irgendetwas komme ich da nicht weiter
es könnte sein das Daten des Flugs helfen, z.B. mit dem NT Logger
idealerweise würdest du die Vorgehensweiss finden wie du das bei dir im Garten reproduzieren kannst, dann könnte ich das bei mir versuchen, und wenn ich es hinbekomme dann habe ich auch was um das zu analysieren
bei dir hört sich das ja so an als ob das regelmässig wenn nicht gar jedesmal auftritt, d.h. es müsste schon möglich sein eine genaue Versuchsanleitung anzugeben, was man machen muss um es zu beobachten.
Als Beispiel: Vor nicht zu langer Zeit gab es mal Jemanden der so komische ganz kurze aber markante Zucker im Video hatte, war klar im Video zu sehen, aber ja mei, woher soll ich den wissen was das ist, da gab's vorher auch nie nen Bericht. Der Jemand hat dann phantastische Detektiv-Arbeit geleistet, hat rausgefunden dass das Zucken in exakt periodischen Abständen von 43s oder so auftritt, und nur dann wenn man LipoCorrection aktiviert, und schwups war das Problem im Code gefunden und gelöst !!! Das Problem war übrigens extrem subtuil, die Änderung im Code war so das jeder Programierer sagen würde dass darf doch keinen Unterschied mache, machte sie aber (evtl Compiler Problem?). Ist also ein drastisches Beispiel eines Falls wo man sich beim Betrachten des Codes die Augen ausstaren kann.
diese schei... FPVC Auslogzeitgrenze ... die ist doch zum kot...n. grrrr
Hallo Zusammen,
vor ein paar Tagen habe ich von dem Problem meiner YAW-Achse berichtet http://fpv-community.de/showthread....bal-Controller&p=890117&viewfull=1#post890117
Danke für alle Tipps, leider konnte ich bis heute nicht so richtig nachvollziehen wie ich feststellen kann ob eine der Imus teilweise defekt ist. Ich habe die Camera IMU getauscht und natürlich nochmals alles neu kalibriert, der Fehler der YAW-Achse blieb der selbe.
Da ich aktuell zwei identische Gimbals aufgebaut hatte und bei dem guten nicht das Problem da ist, tippe ich nach wie vor auf die onboard IMU!? Ich bin in Sachen Software und hohe Elektrokunst leider nicht so tief drin, daher habe ich versucht über Fehlersuche und Ausschlussverfahren dem Problem zu nähern und den Controller getauscht, dummerweise habe ich ein Mega Fehler bei der Erstmaligen Inbetriebnahme gemacht und das Board in Rauch auflösen lassen! .... grrrr! ;-(
So aktuell ist wieder das "defekte??" alte board drauf und macht wieder das Problem beim erreichen des YAW-Ziels.
Ich habe Versucht wie hier vorzugehen:
http://fpv-community.de/showthread....bal-Controller&p=878237&viewfull=1#post878237
Ich verstehe es aber nicht wie ich hieraus interpretieren soll ob die Onboard IMU richtig funktioniert?
Gibt es irgend eine Möglichkeit die Sensor Daten zu bewerten?
Sorry, ich befürchte ich stehe auf der Leitung.
Hier zumindest die funktionierende Mobius 3Achs mit 360° Version, mit AV-Ausgang Beamer im Hintergrund und RC-Signal + YAW Bewegung von Aussen.
https://youtu.be/Rl4W7dF3Md0
Bei dieser Version bin ich jedoch an der Elektrischen grenze was Störungsempfindlichkeit angeht, ich wünschte es gäbe ein EMV-Spray! ;-)
vor ein paar Tagen habe ich von dem Problem meiner YAW-Achse berichtet http://fpv-community.de/showthread....bal-Controller&p=890117&viewfull=1#post890117
Danke für alle Tipps, leider konnte ich bis heute nicht so richtig nachvollziehen wie ich feststellen kann ob eine der Imus teilweise defekt ist. Ich habe die Camera IMU getauscht und natürlich nochmals alles neu kalibriert, der Fehler der YAW-Achse blieb der selbe.
Da ich aktuell zwei identische Gimbals aufgebaut hatte und bei dem guten nicht das Problem da ist, tippe ich nach wie vor auf die onboard IMU!? Ich bin in Sachen Software und hohe Elektrokunst leider nicht so tief drin, daher habe ich versucht über Fehlersuche und Ausschlussverfahren dem Problem zu nähern und den Controller getauscht, dummerweise habe ich ein Mega Fehler bei der Erstmaligen Inbetriebnahme gemacht und das Board in Rauch auflösen lassen! .... grrrr! ;-(
So aktuell ist wieder das "defekte??" alte board drauf und macht wieder das Problem beim erreichen des YAW-Ziels.
Ich habe Versucht wie hier vorzugehen:
http://fpv-community.de/showthread....bal-Controller&p=878237&viewfull=1#post878237
Ich verstehe es aber nicht wie ich hieraus interpretieren soll ob die Onboard IMU richtig funktioniert?
Gibt es irgend eine Möglichkeit die Sensor Daten zu bewerten?
Sorry, ich befürchte ich stehe auf der Leitung.
Hier zumindest die funktionierende Mobius 3Achs mit 360° Version, mit AV-Ausgang Beamer im Hintergrund und RC-Signal + YAW Bewegung von Aussen.
https://youtu.be/Rl4W7dF3Md0
Bei dieser Version bin ich jedoch an der Elektrischen grenze was Störungsempfindlichkeit angeht, ich wünschte es gäbe ein EMV-Spray! ;-)
Zuletzt bearbeitet:
leider beantwortest du einfache Fragen nicht, die über Ausschlussgeben könnten, wie z.B.
ja, gibt es, dazu sind Daten da. Wenn man da nicht selber weiterkommt (was nicht ungewöhnlich ist), gibt es die Möglichkeit das Ergebnis hier zu posten ... in dem Punkt bist du NICHT wie in http://fpv-community.de/showthread....bal-Controller&p=878237&viewfull=1#post878237 vorgegangen
(ansonsten, cooles Projekt)
ja, gibt es, dazu sind Daten da. Wenn man da nicht selber weiterkommt (was nicht ungewöhnlich ist), gibt es die Möglichkeit das Ergebnis hier zu posten ... in dem Punkt bist du NICHT wie in http://fpv-community.de/showthread....bal-Controller&p=878237&viewfull=1#post878237 vorgegangen
(ansonsten, cooles Projekt)
Moin Olli
Ich habe während der letzten Woche immer wieder daran rumstudiert. Es gibt 2 Möglichkeiten. Die eine ist ein mechanisches Problem, z.B. dass der Yaw Gimbalmotor zwischendurch ansteht. Oder eben ein Softwareproblem, sei es ungünstige Einstellwerte oder sonst was.
Da ich das Problem eigentlich nur in der Luft habe, spricht es eher gegen ein mechanisches Problem. Ich verwende ja das genau gleiche Gimbal auch am Boden und konnte bis jetzt nichts merkwürdiges feststellen. Allerdings kann es auch sein, dass es am Boden fast nicht sichtbar ist, da generell mehr Bewegung im Bild ist.
Weiter habe ich mich durch Vimeo und Youtube geklickt, um zu schauen wie's bei anderen so ausschaut. Ich fand einige Videos mit einem sehr ausgeprägten "Yaw-Hänger Effekt" aber auch solche wo der Effekt nicht/kaum wahrnehmbar ist. Besonders stark sichtbar ist es im Video von Andi (GeckoCH) wo er zum Turm aufsteigt (Venedig).
Ein Unterschied zwischen Boden und Luftaufnahmen sind mögliche Fliehkräfte. Mache ich am Boden mit dem Handgimbal eine Yaw Drehung gibt es keine oder nur minimale Fliehkräfte. Fliege ich allerdings mit 50km/h um ein Objekt rum, sieht die Sache wieder etwas anders aus.
Wenn ich mich zurück zu meinen Alexmos Zeiten erinnere, würde ich fast meinen, dass die Yaw Achse unendlich lange brauchte um wirklich still zu stehen. ev. hatte Alexmos das gleiche Problem und behob es indem er gar nie ganz auf den Sollwert korrigierte. Sprich die Yaw Achse hinkt immer dem Sollwert hinter her und ist dadurch immer in Bewegung. Ich frage mich eben, ob bei dir nicht in einer Drehung zwischendurch der Sollwert erreicht wird. So sagt sich der Controller, tiptop Sollwert erreicht, ich mache nichts mehr. Einen kurze Zeit später, Mist es ist eine Abweichung da, ich muss wieder korrigieren. Und dadurch entstehen ev. kurze Aussetzer in der Yaw Drehung.
Leider sind das alles Vermutungen, eigentlich müsste man Soll und Istpositionen, oder/und allfällige sonstige Werte mitloggen können.
Ich sehe, es bleibt spannend. Die Welt ohne technische Probleme wäre doch viel zu langweilig
So, vorest mal genug gelabbert
Gruss Michael
Ich habe während der letzten Woche immer wieder daran rumstudiert. Es gibt 2 Möglichkeiten. Die eine ist ein mechanisches Problem, z.B. dass der Yaw Gimbalmotor zwischendurch ansteht. Oder eben ein Softwareproblem, sei es ungünstige Einstellwerte oder sonst was.
Da ich das Problem eigentlich nur in der Luft habe, spricht es eher gegen ein mechanisches Problem. Ich verwende ja das genau gleiche Gimbal auch am Boden und konnte bis jetzt nichts merkwürdiges feststellen. Allerdings kann es auch sein, dass es am Boden fast nicht sichtbar ist, da generell mehr Bewegung im Bild ist.
Weiter habe ich mich durch Vimeo und Youtube geklickt, um zu schauen wie's bei anderen so ausschaut. Ich fand einige Videos mit einem sehr ausgeprägten "Yaw-Hänger Effekt" aber auch solche wo der Effekt nicht/kaum wahrnehmbar ist. Besonders stark sichtbar ist es im Video von Andi (GeckoCH) wo er zum Turm aufsteigt (Venedig).
Ein Unterschied zwischen Boden und Luftaufnahmen sind mögliche Fliehkräfte. Mache ich am Boden mit dem Handgimbal eine Yaw Drehung gibt es keine oder nur minimale Fliehkräfte. Fliege ich allerdings mit 50km/h um ein Objekt rum, sieht die Sache wieder etwas anders aus.
Wenn ich mich zurück zu meinen Alexmos Zeiten erinnere, würde ich fast meinen, dass die Yaw Achse unendlich lange brauchte um wirklich still zu stehen. ev. hatte Alexmos das gleiche Problem und behob es indem er gar nie ganz auf den Sollwert korrigierte. Sprich die Yaw Achse hinkt immer dem Sollwert hinter her und ist dadurch immer in Bewegung. Ich frage mich eben, ob bei dir nicht in einer Drehung zwischendurch der Sollwert erreicht wird. So sagt sich der Controller, tiptop Sollwert erreicht, ich mache nichts mehr. Einen kurze Zeit später, Mist es ist eine Abweichung da, ich muss wieder korrigieren. Und dadurch entstehen ev. kurze Aussetzer in der Yaw Drehung.
Leider sind das alles Vermutungen, eigentlich müsste man Soll und Istpositionen, oder/und allfällige sonstige Werte mitloggen können.
Ich sehe, es bleibt spannend. Die Welt ohne technische Probleme wäre doch viel zu langweilig
So, vorest mal genug gelabbert
Gruss Michael
G
hmm könnte es also sein das meine pitch PIDS da mit rein wirken? die hatte ich nie verändert und immer nur an yaw rum gedocktort. dachte pitch passt alleine geht das ja einwandfrei, deswegen sind meine pitch pids recht "hart".
wenn du sagst das könnte ein problem sein. dann wird das der letzte versuch in den ich noch etwas zeit stecke ^^
wenn du sagst das könnte ein problem sein. dann wird das der letzte versuch in den ich noch etwas zeit stecke ^^
Ich habe nun exakt den Versuch unternommen.
1. Gimbal Passiv bewegt über alle Achsen, siehe Bild
2. Gimbal aktiv, zuerst mit PanYaw 0 (Siehe Foto *A) dann mit PanYaw 2,5 (siehe Foto *B) + Datei Settings aktiv.txt
Zusätzlich meine Einstellungen.
Anhang anzeigen Settings2 aktiv zuerst mit YAWPAN0 dann mit YAWPan 2,5 und zucken.txt
Ab Aktivierung der Yaw-Pan fängt YAW an zu schwingen sobald es den 0-Punkt haben sollte.
Identische Einstellungen und Identischer Aufabu am zweiten Gimbal machen keine Probleme!
Ich werde nicht schlau daraus, wie kann ich den Fehler nun weiter eingrenzen?
(ansonsten, cooles Projekt)
.... hoffen wir dass die letzten 2% auch noch werden!
1. also, die Antwort wird sein: ja, ohne 2ter Imu geht es
2. wie auch bei der Diskussion mit _Rolf erwähnt, MÜSSEN die Linien im Unteren Plot (A&B) mit 2ter IMU IMMER nahe der Null sein ... was bei dir ganz offensichtlich nicht de Fall ist
=> du hast gar kein Yaw Problem, sondern du hast irgendetwas grundsätzlich falsch konfiguriert
(wenn man ne kaputte Imu mal nict als ersten Grund annimmt)
3. ein Blick in die Parameter zeigt dass du für Roll&Pitch 12 Pole angegeben hast ???? die Walkeramotoren haben aber 14
=> probiere es mal mit richtigen Einstellungen
2. wie auch bei der Diskussion mit _Rolf erwähnt, MÜSSEN die Linien im Unteren Plot (A&B) mit 2ter IMU IMMER nahe der Null sein ... was bei dir ganz offensichtlich nicht de Fall ist
=> du hast gar kein Yaw Problem, sondern du hast irgendetwas grundsätzlich falsch konfiguriert
(wenn man ne kaputte Imu mal nict als ersten Grund annimmt)
3. ein Blick in die Parameter zeigt dass du für Roll&Pitch 12 Pole angegeben hast ???? die Walkeramotoren haben aber 14
=> probiere es mal mit richtigen Einstellungen
@amadeus:
es könnte sein, aber ich möchte mich da keine Aussage zu machen ... ich verstehe es nicht wirklich, also kann alles was ich sage richtig oder falsch sein ... ich weis es nicht
@buckker:
ich meinte auch nicht dass man am Boden irgendetwas macht, sondern das was in der Luft passiert am Boden nachstellt
ich habe das so interpretiert, dass du das machst was bei Solo wohl Orbit heisst, also im Kreis um das Objekt fliegst und dabei den Copter mit der Schnauze aufs Objekt zeigen lässt, du die Kamera/Gimbal aber selber nicht aktiv steuerst
GekoCHs video ist ganz anders geflogen, und das Yaw Hackeln dort ist - IMHO - das mit dem "an der Deadbandgrenze hängenbleiben", hatten wir glaube ich auch mal diskutiert. In dem Video scheint GekoCH eine recht große Gyro Drift zu haben, so dass das sehr stark wird. Da gibt es auch von anderen Videos wo man das hinundwieder sehen kann. Das Yaw Hackeln dort glaube ich also zu verstehen.
Dein Fall scheint mir anders. Wenn ich das richtig verstehe hast du nen sehr kleines Deadband, Hysterse und Limiter und Pan weis ich nicht mehr (die Dropbox ist leider leer), d.h. ich denke bei dem konstanten Drehen des Kopters sollte sich die Kamera immer ausreichend weg von der Deadbandgrenze befinden, bzw. war das ja der Ansatz den wir mal diskutiert hatten und dazu geführt hatte schwaches Pan aber dafür Limiter zu benutzen. Kurz um, ich nehme an dass die Kamera beim ganzen Schwenk immer weit von der Deadbandgrenze weg ist.
Anders gesagt, ich gehe davon aus dass dir das Orbitmaneuver ganz gut gelingt, so dass der Kopter sauber herum orbited, ohne mit der Nase stark zu wedeln. (wenn die Nase stark wedelt, dann kann es gut das an der Deadbandgrenzefesthängen-Problem sein)
Was du am Boden testen könntest wäre z.B. mit dem Kopter/Gimbal in nem z.B. 5m Radius um das Objekt herrum rennen, und zwar so schnell/langsam dass du das Objekt in etwa in der selben Zeit umrundest wie im Flug. Dann kannst du ja genau sehen wie weit die Kamera der Kopternase hinterherhängt ... sie sollte bei dem Maneuver immer soweit nachhinken, dass sie immer gut ausserhalb des Deadbans ist.
Wenn man so nicht weiterkommt, bleibt nur Gimbal-Daten während des Flugs aufzunehmen.
es könnte sein, aber ich möchte mich da keine Aussage zu machen ... ich verstehe es nicht wirklich, also kann alles was ich sage richtig oder falsch sein ... ich weis es nicht
@buckker:
ich meinte auch nicht dass man am Boden irgendetwas macht, sondern das was in der Luft passiert am Boden nachstellt
ich habe das so interpretiert, dass du das machst was bei Solo wohl Orbit heisst, also im Kreis um das Objekt fliegst und dabei den Copter mit der Schnauze aufs Objekt zeigen lässt, du die Kamera/Gimbal aber selber nicht aktiv steuerst
GekoCHs video ist ganz anders geflogen, und das Yaw Hackeln dort ist - IMHO - das mit dem "an der Deadbandgrenze hängenbleiben", hatten wir glaube ich auch mal diskutiert. In dem Video scheint GekoCH eine recht große Gyro Drift zu haben, so dass das sehr stark wird. Da gibt es auch von anderen Videos wo man das hinundwieder sehen kann. Das Yaw Hackeln dort glaube ich also zu verstehen.
Dein Fall scheint mir anders. Wenn ich das richtig verstehe hast du nen sehr kleines Deadband, Hysterse und Limiter und Pan weis ich nicht mehr (die Dropbox ist leider leer), d.h. ich denke bei dem konstanten Drehen des Kopters sollte sich die Kamera immer ausreichend weg von der Deadbandgrenze befinden, bzw. war das ja der Ansatz den wir mal diskutiert hatten und dazu geführt hatte schwaches Pan aber dafür Limiter zu benutzen. Kurz um, ich nehme an dass die Kamera beim ganzen Schwenk immer weit von der Deadbandgrenze weg ist.
Anders gesagt, ich gehe davon aus dass dir das Orbitmaneuver ganz gut gelingt, so dass der Kopter sauber herum orbited, ohne mit der Nase stark zu wedeln. (wenn die Nase stark wedelt, dann kann es gut das an der Deadbandgrenzefesthängen-Problem sein)
Was du am Boden testen könntest wäre z.B. mit dem Kopter/Gimbal in nem z.B. 5m Radius um das Objekt herrum rennen, und zwar so schnell/langsam dass du das Objekt in etwa in der selben Zeit umrundest wie im Flug. Dann kannst du ja genau sehen wie weit die Kamera der Kopternase hinterherhängt ... sie sollte bei dem Maneuver immer soweit nachhinken, dass sie immer gut ausserhalb des Deadbans ist.
Wenn man so nicht weiterkommt, bleibt nur Gimbal-Daten während des Flugs aufzunehmen.
1. also, die Antwort wird sein: ja, ohne 2ter Imu geht es
2. wie auch bei der Diskussion mit _Rolf erwähnt, MÜSSEN die Linien im Unteren Plot (A&B) mit 2ter IMU IMMER nahe der Null sein ... was bei dir ganz offensichtlich nicht de Fall ist
=> du hast gar kein Yaw Problem, sondern du hast irgendetwas grundsätzlich falsch konfiguriert
(wenn man ne kaputte Imu mal nict als ersten Grund annimmt)
3. ein Blick in die Parameter zeigt dass du für Roll&Pitch 12 Pole angegeben hast ???? die Walkeramotoren haben aber 14
=> probiere es mal mit richtigen Einstellungen
2. wie auch bei der Diskussion mit _Rolf erwähnt, MÜSSEN die Linien im Unteren Plot (A&B) mit 2ter IMU IMMER nahe der Null sein ... was bei dir ganz offensichtlich nicht de Fall ist
=> du hast gar kein Yaw Problem, sondern du hast irgendetwas grundsätzlich falsch konfiguriert
(wenn man ne kaputte Imu mal nict als ersten Grund annimmt)
3. ein Blick in die Parameter zeigt dass du für Roll&Pitch 12 Pole angegeben hast ???? die Walkeramotoren haben aber 14
=> probiere es mal mit richtigen Einstellungen
OlliW, du bist echt ein Fuchs! ;-)
und Schande über mein Haupt
Als erstes habe ich nun die Pole richtig auf 14 eingestellt, Anfängerfehler, habe in der Tat die Walkera in der Vergangenheit immer mit 12pol angenommen, hatte ein Bild von einem Innenläufer vor Augen und anstelle der Magnete die Spulen gezählt!
OK ja es sind 14 Pole und 12 Spulen= Aussenläufer! ;-)
(verwunderlich, dass alle meine Gimbals dennoch bislang alle recht gute liefen, bis auf dieses eine!)
Dann habe ich noch die Pids ewas verändert, hatte Anfangs noch das Problem mit Pan-Yaw (bei bislang immer aktivierter 2ten Imu auf full!) habe nochmals gestored und neumit dem Akku verbunden, tata! nun läuft das Ding! ... bis dahin 100000 DANK!!!!
Leider hängt sich das Gimbal in aktion nach ein paar min auf, evtl. die Sensor-EMV Thematik, was bei meiner Slipring-Lösung natürlich möglich wäre. Seltsam jedoch, dass die Errors auf max 1-4Stk ansteigen und das Gimbal dennoch hängen bleibt?
Anhang anzeigen SettingsERR.txt
Gibt es eine weiter Möglichkeit die Sensor-Fehler-Qualität zu analysieren, außerhalb der einen Err Meldung? Und meinst du ich könnte mit ein paar Kondensatörchen zb. an der Imu oder auf halber Strecke etwas verbessern?
Wie gesagt, ein paar Minuten spielt das Ding astrein!
Oder doch nur möglich mit der NT-IMU?
Zuletzt bearbeitet:
