NAZE32 - alternative Software
- Themenstarter JUERGEN_
- Beginndatum
- Status
Hi,
habe gestern mal den neuen Code von Rob getestet,
Fliegt sich im Std. Setup wunderbar wie die SG2.6Pre.
Die LED Sequenzen sind übersichtlicher und die neue ACC kalibrierung sehen gut aus.
PH geht sehr gut. Nur bei schnellen Flügen und Loslassen der Steuerknüppel fliegt er weiter und fängt an plötzlich wieder zurückzudriften um einen PH zu machen.
Würde ihn ganz gerne ein wenig ausdriften lassen und danach darf er im PH Modus einrasten.
Ist das richtig wenn ich den wert auf 1000-1500ms stelle?
Muss die Sttlespeed da evtl auch etwas angehoben werden?
gps.c:
#define PhStickCenterTimeout 300 // Defines the time in ms when we consider the sticks really back to center
#define PhSettleTimeout 410 // Defines the time in ms, where actual speed must be below settlespeed, to consider a settled copter
Hoffe ich liege hier nicht völlig falsch ...
Aber ansonsten ... TOP!
Gruss
Frank
habe gestern mal den neuen Code von Rob getestet,
Fliegt sich im Std. Setup wunderbar wie die SG2.6Pre.
Die LED Sequenzen sind übersichtlicher und die neue ACC kalibrierung sehen gut aus.
PH geht sehr gut. Nur bei schnellen Flügen und Loslassen der Steuerknüppel fliegt er weiter und fängt an plötzlich wieder zurückzudriften um einen PH zu machen.
Würde ihn ganz gerne ein wenig ausdriften lassen und danach darf er im PH Modus einrasten.
Ist das richtig wenn ich den wert auf 1000-1500ms stelle?
Muss die Sttlespeed da evtl auch etwas angehoben werden?
gps.c:
#define PhStickCenterTimeout 300 // Defines the time in ms when we consider the sticks really back to center
#define PhSettleTimeout 410 // Defines the time in ms, where actual speed must be below settlespeed, to consider a settled copter
Hoffe ich liege hier nicht völlig falsch ...
Aber ansonsten ... TOP!
Gruss
Frank
Zuletzt bearbeitet:
Hi Franko!
Besten Dank für die positive Rückmeldung. Du kannst auch die angenommene Bremsgeschwindigkeit anpassen. gps_ph_brkacc ist 40 voreingestellt. D.h. es wird eine "Bremswirkung" (also eigentlich eine negative Beschleunigung) von 40 cm/(s*s) angenommen.
Es wird dann so gerechnet:
z.B Dein copter fliegt mit 500 cm/s und Deine Zeilgeschwindigkeit (gps_ph_settlespeed = 10 Default) ist 10 cm/s.
Dann ist die Differenz 490cm/s die man "wegbremsen" muss (mit den vorgegebenen Winkeln gps_ph_brakemaxangle und gps_ph_minbrakepercent). Die erwartete, benötigte Zeit mit der Bremswirkung wäre dann (490cm/s) / (40cm/(s*s)) = 12.25 Sekunden. Allerdings habe ich die Maximale Bremszeit auf 5 Sekunden reduziert (gps.c Zeile 146 "PhTimer1 = currentTimeMS + constrain(((..... 1, 5000);"), weil es unklar ist, wie der Wind da mitspielt, d.h. nach 5 Sekunden ist spätestens der Bremsofen aus, ausser die Zielgeschwindigkeit wird vorher unterschritten. Wenn das erledigt ist, wird noch das angenommene GPS lag ("gps_lag") abgewartet (die "Position zieht nach") und dann das vom GPS gemeldete Koordinatenpaar als PH Position genommen (da fliegt er ggf. dann etwas zurück).
Also "gps_lag" ist also nicht wirklich das GPS lag (d.h. ein Koordinatenpaar aus vergangenen extrapoliert) sondern eine Extrazeit. Das Vorausberechnen von GPS Koordinaten hatte bei mir mehr Probleme als Nutzen gebracht.
Das muss sowieso noch geändert werden, ich wollte Dir nur schreiben, nach welcher Logik das aktuell läuft.
LG
Rob
Besten Dank für die positive Rückmeldung. Du kannst auch die angenommene Bremsgeschwindigkeit anpassen. gps_ph_brkacc ist 40 voreingestellt. D.h. es wird eine "Bremswirkung" (also eigentlich eine negative Beschleunigung) von 40 cm/(s*s) angenommen.
Es wird dann so gerechnet:
z.B Dein copter fliegt mit 500 cm/s und Deine Zeilgeschwindigkeit (gps_ph_settlespeed = 10 Default) ist 10 cm/s.
Dann ist die Differenz 490cm/s die man "wegbremsen" muss (mit den vorgegebenen Winkeln gps_ph_brakemaxangle und gps_ph_minbrakepercent). Die erwartete, benötigte Zeit mit der Bremswirkung wäre dann (490cm/s) / (40cm/(s*s)) = 12.25 Sekunden. Allerdings habe ich die Maximale Bremszeit auf 5 Sekunden reduziert (gps.c Zeile 146 "PhTimer1 = currentTimeMS + constrain(((..... 1, 5000);"), weil es unklar ist, wie der Wind da mitspielt, d.h. nach 5 Sekunden ist spätestens der Bremsofen aus, ausser die Zielgeschwindigkeit wird vorher unterschritten. Wenn das erledigt ist, wird noch das angenommene GPS lag ("gps_lag") abgewartet (die "Position zieht nach") und dann das vom GPS gemeldete Koordinatenpaar als PH Position genommen (da fliegt er ggf. dann etwas zurück).
Also "gps_lag" ist also nicht wirklich das GPS lag (d.h. ein Koordinatenpaar aus vergangenen extrapoliert) sondern eine Extrazeit. Das Vorausberechnen von GPS Koordinaten hatte bei mir mehr Probleme als Nutzen gebracht.
Das muss sowieso noch geändert werden, ich wollte Dir nur schreiben, nach welcher Logik das aktuell läuft.
LG
Rob
Zuletzt bearbeitet:
Danke Rob, werde es mir mal in einer ruhigen Minute anschauen.
War eben gerade fliegen... GPS Hold und auch RTH funktionieren, aber mir sind zwei Sachen aufgefallen:
1. GPS Hold hatte heute einen TBE, den hatte ich mit SG2.6Pre noch nie.
Der Copter ist tlws. im 2-3 Meter Radius gekreist. (gut von 8 Versuchen 2 Mal)
Mag Probleme kann ich aussschliessen, habe einen externen Mag und das hatte mit 2.6Pre ohne TBE funktioniert.
2. RTH geht sehr gut, nur einmal blieb er bei 5 Meter Höhe stehen und beim letzten von 5 Versuchen machte er einen Autoland mit Hüpfern. Satelliten habe ich 7-8 gehabt, drunter versuche ich nichts.
Jetzt weiss ich nicht was Standardmässig aktiviert ist, weil Autoland brauche ich nicht.. Copter kann in einer Höhe von 2-3 Metern bleiben.
Nach der ACC inflight calibration steht der Copter fast angenagelt in der Luft.
Für die Grösse meines Copters (kleiner DIN A4 und 4.5" Props) fliegt es sich sehr gut und ich hoffe meine neue BOSCAm TX kommt bald fürs FPV fliegen.
Nun muss ich mal schauen wie ich das mit dem Bremsen geregelt bekomme. Momentan ist nach Erhöhung der Werte in gps.c m.M schlechter geworden:
#define PhStickCenterTimeout 1500
#define PhSettleTimeout 800
ich drifte etwas länger(permanenter GPS Hold Flug), aber danach werde ich wieder 7-10 Meter zurückgezogen um dann wieder 3 Meter vorwärts einzurasten. (Sieht ein wenig aus wie eine langsame Schiffsschaukel)
Wie gesagt, ich schaue mir das in Ruhe am WE an.
LG
Frank
War eben gerade fliegen... GPS Hold und auch RTH funktionieren, aber mir sind zwei Sachen aufgefallen:
1. GPS Hold hatte heute einen TBE, den hatte ich mit SG2.6Pre noch nie.
Der Copter ist tlws. im 2-3 Meter Radius gekreist. (gut von 8 Versuchen 2 Mal)
Mag Probleme kann ich aussschliessen, habe einen externen Mag und das hatte mit 2.6Pre ohne TBE funktioniert.
2. RTH geht sehr gut, nur einmal blieb er bei 5 Meter Höhe stehen und beim letzten von 5 Versuchen machte er einen Autoland mit Hüpfern. Satelliten habe ich 7-8 gehabt, drunter versuche ich nichts.
Jetzt weiss ich nicht was Standardmässig aktiviert ist, weil Autoland brauche ich nicht.. Copter kann in einer Höhe von 2-3 Metern bleiben.
Nach der ACC inflight calibration steht der Copter fast angenagelt in der Luft.
Für die Grösse meines Copters (kleiner DIN A4 und 4.5" Props) fliegt es sich sehr gut und ich hoffe meine neue BOSCAm TX kommt bald fürs FPV fliegen.
Nun muss ich mal schauen wie ich das mit dem Bremsen geregelt bekomme. Momentan ist nach Erhöhung der Werte in gps.c m.M schlechter geworden:
#define PhStickCenterTimeout 1500
#define PhSettleTimeout 800
ich drifte etwas länger(permanenter GPS Hold Flug), aber danach werde ich wieder 7-10 Meter zurückgezogen um dann wieder 3 Meter vorwärts einzurasten. (Sieht ein wenig aus wie eine langsame Schiffsschaukel)
Wie gesagt, ich schaue mir das in Ruhe am WE an.
LG
Frank
Zuletzt bearbeitet:
Erstaunlich, dass es überhaupt auf dem kleinen Flieger läuft mit den Std Werten. Mein Testcopter ist ein behäbiger DJI 450 1,1Kg copter.
Mit dem Aufkreisen muss ich auch noch mal schauen. Da ist allerdings leider auch eine Version mit sehr hohem cpfm heraus gegangen, das führt dann dazu, dass das MAG nicht mehr die Gyrodrift korrigieren kann. Zum Anderen habe ich die ACC Summation jetzt geändert, ich drehe erst und dann lowpass und Summation. Vorher war es erst im Bodyframe LPF dann in das Earthframe drehen und aufaddieren. Ich hatte den Eindruck, dass es durch "erst in das EF drehen" besser beim Gieren im PH ist, muss aber auch noch weiter testen, vielleicht stelle ich das wieder um. Gottlob ist das Wetter jetzt besser. Ach, ja das Kreisen kann bei Dir auch von dem "I" kommen, drehe das mal versuchsweise auf 0.
Übrigens die vormals "inflight cal" ist jetzt keine Kalibration mehr sondern es werden nur Trimwerte bestimmt. So, als wenn man zwischenlanden würde und die Trimmung knüppelt. Die ACC Kalibration ist jetzt deutlich aufwändiger und lässt sich im Flug nicht bewerkstelligen, da auch u.a das Sensorrauschen um den Nullpunkt bestimmt wird.
LG
Rob
Mit dem Aufkreisen muss ich auch noch mal schauen. Da ist allerdings leider auch eine Version mit sehr hohem cpfm heraus gegangen, das führt dann dazu, dass das MAG nicht mehr die Gyrodrift korrigieren kann. Zum Anderen habe ich die ACC Summation jetzt geändert, ich drehe erst und dann lowpass und Summation. Vorher war es erst im Bodyframe LPF dann in das Earthframe drehen und aufaddieren. Ich hatte den Eindruck, dass es durch "erst in das EF drehen" besser beim Gieren im PH ist, muss aber auch noch weiter testen, vielleicht stelle ich das wieder um. Gottlob ist das Wetter jetzt besser. Ach, ja das Kreisen kann bei Dir auch von dem "I" kommen, drehe das mal versuchsweise auf 0.
Übrigens die vormals "inflight cal" ist jetzt keine Kalibration mehr sondern es werden nur Trimwerte bestimmt. So, als wenn man zwischenlanden würde und die Trimmung knüppelt. Die ACC Kalibration ist jetzt deutlich aufwändiger und lässt sich im Flug nicht bewerkstelligen, da auch u.a das Sensorrauschen um den Nullpunkt bestimmt wird.
LG
Rob
Kleiner Hummel - Hüpfer 
.
Das ist das Pos I. Posr I wird nicht verwendet. Das ist jetzt so gelöst, wenn man das PosrI setzt, wird es als 0 gespeichert, damit man direkt beim reload sieht, dass man einen nicht verwendeten Wert gesetzt hat. EDIT: Habe die D Wert Berechnung nochmal geändert, mal sehen was das bringt.
Der Hüpfer beim Landen kommt leider durch den Bodeneffekt und die Tatsache, dass das Barometer unterhalb der engstehenden Propeller misst, es ist kein ACC Effekt (wie ich zuerst dachte), sondern das Luftkissen und der Baro mitten drin. Zum einen kann insbes. Dein Alt P zu hoch sein, so dass die zwangsläufige Fehlmessung zu stark durchschlägt zum anderen kann der Debouncer nicht scharf genug eingestellt sein.
Mein "Antihüpfer" ("Debouncer") funktioniert ganz einfach:
Beim Einleiten der Autolandung wird erst gewartet und das aktuelle Schwebegas gemittelt und als obere Grenze zum Abriegeln genommen. Dann kommt er allerdings eher wie ein Stein herunter, weil er zwischenzeitlich eben doch noch etwas mehr Gas geben können muss um die Landung langsamer zu machen. Deswegen kann man einen Prozentwert angeben um den das Schwebegas überschritten werden darf. Voreingestellt sind 5% (al_debounce = 5), weil die perfekt auf meinem Copter laufen. Dein Copter hängt offensichtlich wesentlich besser am Gas als mein Brummer, deswegen vllt. Alt P etwas reduzieren (vllt von 10 auf 9?) oder direkt den al_debounce mal auf 3 setzen oder beides oder... weiss der Henker.
LG
Rob
EDIT: 14.3: Bin weiter gekommen. Habe bei der PH Bremsung noch was gefunden und noch etwas bei der Berechnung des GPS D Anteils (sehr wahrscheinlich mitverantwortlich für das Kreisen). Irgendwas stimmt beim RTH noch mit dem tail heading nicht, da wollte ich noch ran.
Es ist also wieder was im Anmarsch...
.Das ist das Pos I. Posr I wird nicht verwendet. Das ist jetzt so gelöst, wenn man das PosrI setzt, wird es als 0 gespeichert, damit man direkt beim reload sieht, dass man einen nicht verwendeten Wert gesetzt hat. EDIT: Habe die D Wert Berechnung nochmal geändert, mal sehen was das bringt.
Der Hüpfer beim Landen kommt leider durch den Bodeneffekt und die Tatsache, dass das Barometer unterhalb der engstehenden Propeller misst, es ist kein ACC Effekt (wie ich zuerst dachte), sondern das Luftkissen und der Baro mitten drin. Zum einen kann insbes. Dein Alt P zu hoch sein, so dass die zwangsläufige Fehlmessung zu stark durchschlägt zum anderen kann der Debouncer nicht scharf genug eingestellt sein.
Mein "Antihüpfer" ("Debouncer") funktioniert ganz einfach:
Beim Einleiten der Autolandung wird erst gewartet und das aktuelle Schwebegas gemittelt und als obere Grenze zum Abriegeln genommen. Dann kommt er allerdings eher wie ein Stein herunter, weil er zwischenzeitlich eben doch noch etwas mehr Gas geben können muss um die Landung langsamer zu machen. Deswegen kann man einen Prozentwert angeben um den das Schwebegas überschritten werden darf. Voreingestellt sind 5% (al_debounce = 5), weil die perfekt auf meinem Copter laufen. Dein Copter hängt offensichtlich wesentlich besser am Gas als mein Brummer, deswegen vllt. Alt P etwas reduzieren (vllt von 10 auf 9?) oder direkt den al_debounce mal auf 3 setzen oder beides oder... weiss der Henker.
LG
Rob
EDIT: 14.3: Bin weiter gekommen. Habe bei der PH Bremsung noch was gefunden und noch etwas bei der Berechnung des GPS D Anteils (sehr wahrscheinlich mitverantwortlich für das Kreisen). Irgendwas stimmt beim RTH noch mit dem tail heading nicht, da wollte ich noch ran.
Es ist also wieder was im Anmarsch...
Zuletzt bearbeitet:
Hi, Yups mit Graupner kenne ich mich nicht aus. Ich glaube BF hat das aber drin. In der Richtung habe ich nichts in Planung.
OT: Habe jetzt mal die Idee hier getestet: http://diydrones.com/profiles/blogs/arducopter-motor-response-compensation. Bringt was für normale ESC bei BLheli geflashten sah es eher mau aus...
OT: Habe jetzt mal die Idee hier getestet: http://diydrones.com/profiles/blogs/arducopter-motor-response-compensation. Bringt was für normale ESC bei BLheli geflashten sah es eher mau aus...
Hey Roberto,
die seriellen Empfänger sind eine tolle Sache finde ich. Hier im Forum ist noch ein Beitrag con cesco1:
http://fpv-community.de/showthread.php?43946-Naze32-und-serielle-RX
Das müsste doch mit geringem Aufwand aus der BF zu übernehmen sein oder?
die seriellen Empfänger sind eine tolle Sache finde ich. Hier im Forum ist noch ein Beitrag con cesco1:
http://fpv-community.de/showthread.php?43946-Naze32-und-serielle-RX
Das müsste doch mit geringem Aufwand aus der BF zu übernehmen sein oder?
Das ist mir doch alles bewusst und ich habe auch schon mal angefangen ein Naze32 Layout mit etwas größerem STM32 zu zeichnen um das Problem zu umschiffen.
Viele verwenden ihre Naze32 aber auch für einen Bolzkopter ohne GPS, da ist dann min. ein UART frei. SumPPM habe ich jetzt auch im Einsatz (GR-12). Allerdings würde ich gerne das digitale Signal nutzen in Kombination mit einem viel leichteren und billigeren GR-12SC+
(7g vs. 1,6g und gerade einmal halb so viele €).
Viele verwenden ihre Naze32 aber auch für einen Bolzkopter ohne GPS, da ist dann min. ein UART frei. SumPPM habe ich jetzt auch im Einsatz (GR-12). Allerdings würde ich gerne das digitale Signal nutzen in Kombination mit einem viel leichteren und billigeren GR-12SC+
(7g vs. 1,6g und gerade einmal halb so viele €).
Ich bin nicht so in der Materie drin und habe es auch nicht eilig damit. Es wäre nur schön, wenn Roberto oder ein anderer der üblichen Verdächtigen (gibt es eig. auch einen Spendenlink zu der Sache?) in den nächsten Wochen den Teil vielleicht einpflegen könnten. Würde ungerne mit der Baseflight rumfummeln.
Das Thema gab es schon zig mal glaube ich, aber jetzt muss ja nichtmal mehr die Entwicklungsarbeit gemacht werden.
(gibt es eig. auch einen Spendenlink zu der Sache?) in den nächsten Wochen den Teil vielleicht einpflegen könnten. Würde ungerne mit der Baseflight rumfummeln.Das Thema gab es schon zig mal glaube ich, aber jetzt muss ja nichtmal mehr die Entwicklungsarbeit gemacht werden.
@Yups,
Du kannst den angehängten Code mal testen. Ich habe den Baseflight Treibers eingebunden und alle geänderten bzw. neuen Dateien beigefügt. Das Ganze basiert auf Robertos letzen Code und ist aber so ungetestet da ich keinen entsprechenden Graupner Empfänger habe. Wenn der Empfänger geht (sorgfältig in der GUI testen) sollte man auch Acro, Level und Baro problemlos fliegen können. Die GPS Funktionen sind aktuell noch im Test und sollten nur mit guter Flugerfahrung benutzt werden. Vielleicht kann das Roberto nach erfolgreichen Test dann übernehmen. Aus beiden Graupner Protokollen einen Treiber zu machen war mir im Moment zu riskant da ich auch keine wesentlichen Gemeinsamkeiten gefunden habe.
Grüße mj666
Du kannst den angehängten Code mal testen. Ich habe den Baseflight Treibers eingebunden und alle geänderten bzw. neuen Dateien beigefügt. Das Ganze basiert auf Robertos letzen Code und ist aber so ungetestet da ich keinen entsprechenden Graupner Empfänger habe. Wenn der Empfänger geht (sorgfältig in der GUI testen) sollte man auch Acro, Level und Baro problemlos fliegen können. Die GPS Funktionen sind aktuell noch im Test und sollten nur mit guter Flugerfahrung benutzt werden. Vielleicht kann das Roberto nach erfolgreichen Test dann übernehmen. Aus beiden Graupner Protokollen einen Treiber zu machen war mir im Moment zu riskant da ich auch keine wesentlichen Gemeinsamkeiten gefunden habe.
Grüße mj666
- Status
