Der ArduPlane Thread

Es ist gut möglich das verschiedene Digi Servos mit der Ansteuerungsfrequenz der APM nicht klar kommen. Evtl. sinds auch Pseudo Digi Servos mit schlechten Potis, die zappeln auch rum weil die nie den Neutralpunkt finden.
 
Hallo zusammen,
ich habe jetzt erstmalig einen APM im Einsatz und nach anfänglicher Euphorie kämpfe ich gerade mit ein paar kleinen Problemen. Evtl. könnt ihr mir dabei auf die Sprünge helfen, denn ich bin noch nicht sonderlich tief in die Materie eingestiegen.

Der APM 2.5 ist in einem Skywalker 1900 verbaut und hat die aktuelle Software drauf. Das Flugbild der Fliegers ist recht unschön, was aber wohl nicht mit dem APM zusammen hängt. Der Heck hängt immer etwas durch, was man besonders in Kurven und beim langsamen Fliegen deutlich erkennen kann. Auch Seitenruderunterstützung ändert daran kaum etwas (KFF_RDDRMIX derzeit auf 0,4). Aber das sind nur Äußerlichkeiten…

Ein wirkliches Problem habe ich im Satbi-Mode durch ein Aufschaukeln der Querruder. Dieses ist besonders bei höheren Geschwindigkeiten zu beobachten. Wenn dann noch Seitenwind hinzu kommt, geht der Flieger gern übers Taumeln in der Sturzflug über.

Außerdem ist der Flieger im Stabi Mode sehr träge. Man braucht schon sehr große und lange Querrudereingaben, bis sich die Fluglage merklich ändert. Übertreibt man hierbei aber, folgt der zuvor schon erwähnte Taumel- Sturzflug.

Ich versuche mal die Grundeinstellungen als Screenshot beizufügen. Evtl. könnt ihr hieraus schon Schlüsse ziehen, die ich so nicht erkenne.

Besten Dank
Dirk
 

Anhänge

Hi,
grundsätzlich sollte der Flieger erstmal ohne apm sauber fliegen dann würde ich erst mit dem parameter tuning weiter machen. Hierfür gibt es übrigens seit ein paar Tagen auch eine Autotune Funktion.
 

LSG

Erfahrener Benutzer
In meiner Verzweiflung habe ich die nun die Corona Digital-Servos rausgeschmissen und die etwas größeren analogen Servos von Torcster ausprobiert.
Gute Entscheidung! Ich habe 2 Coronaservos mit Metallgetriebe und beide haben an meinem Tri nach einiger Zeit ihren Geist aufgegeben.
Habe nun das unwesentlich teurere "TowerPro MG90 Metal Geared Servo With Bearing" drin, das hat bisher gehalten.
 
Hi,
grundsätzlich sollte der Flieger erstmal ohne apm sauber fliegen dann würde ich erst mit dem parameter tuning weiter machen. Hierfür gibt es übrigens seit ein paar Tagen auch eine Autotune Funktion.
Hi,
grundsätzlich fliegt der Vogel ohne APM recht gut. Der Schwerpunkt wurde mit der „Anstech-Methode“ sauber eingeflogen und deckt sich auch mit den einigen Angaben, die im Netz zu finden sind.

Eine Autotuning Funktion finde ich zwar recht interessant, aber grundsätzlich will ich mich nicht darauf verlassen.

Daher meine Frage noch mal etwas konkreter:
Wie genau wirken sich Änderungen bei den P, I und D Werten aus? Was sagt der INT_MAX Wert und sind die Nick- und Rollwinkel evtl. zu groß bzw. zu klein eingestellt?

Gruß Dirk
 

Drohne

Erfahrener Benutzer
Hallo,
(betrifft Servozappeln),
habe jetzt Digitalservos eingebaut und die Zappelei ist weg. Beim Copter kann man die Ansteuerfrequenz der Regler verändern (Framerate). Beim Flächen- APM habe ich sowas noch nicht gefunden. Evtl würde das reichen. Die ganzen Servos erneuern zu müssen ist auch nicht gerade erfreulich...
 
Da habe ich mir im Missionplanner für Arduplane schon nen Wolf gesucht. Die Ansteuerfrequenz der Regler verändern, würde ja beim Arduplane auch nicht wirklich Sinn machen. Aber es scheint sich doch zu bestätigen . . . .manche Servos wollen einfach nicht . . .
 

kuvera

Erfahrener Benutzer
Hab mich schon ziemlich eingehend mit dem APM und den Parametern der Full Parameter List auseinandergesetzt. Dennoch bedient mich Freund Google nicht mit der Antwort, was für ein Problem das ich habe, wenn mein Seitenruder nur im Manual-Mode die Signale 1:1 weitergibt, aber in sämtlichen anderen Flight-Modes komplett kein Signal zum SR weitergegeben wird. Sogar der Offset des SR ist leicht verschoben. Ziemlich blöd. Ich verwende das APM in der Konfig, wie man es sonst für einen normalen Flächenflieger braucht. Angewendet auf die BigTurtle (bitte keine Diskussion über diesen Flieger hier) mit Querruder und Höhenruder getrennt (keine Delta-Konfig). APM ist ein 2.6. Danke für einen Hinweis, falls ihr ne Idee habt.
//
Lösung gefunden! RC4_min RC4_max richtig setzen wirkt wunder ;)
 
Zuletzt bearbeitet:

AndreasL90

Erfahrener Benutzer
Hat jemand mit dem Digital Airspeed Sensor (I²C) am Pixhawk das gleiche Problem (gehabt), dass die im MP ausgegebenen Werte Sprünge machen, wie in folgendem Screenshot?

Das Auftreten des Peaks ist absolut zufällig, aber trotzallem so häufig, dass es im Flug höchstwarscheinlich Probleme macht.
Der Sensor ist über den I²C Verteiler an den RTFHawk angeschlossen, der wiederrum vom Stromsensor mit Spannung versorgt wird. Die Verbindung zum MP geht über USB.
Ausserdem sind ein S.Bus Empfänger und ein GPS (richtig) angeschlossen (und funktionieren auch perfekt).



Edit: Problem scheint gelöst. Scheinbar tritt es auf, wenn der I²C Verteiler genutzt wird. Die Kabel sind in Ordnung gewesen (hab sie durchgemessen und keinen Wackelkontakt o.ä. gefunden) und in den Logfiles stand (seltsamerweise) nichts von einem I²C Error.
 

Anhänge

Zuletzt bearbeitet:

Drohne

Erfahrener Benutzer
Hallo,
beim Copter kann ich die RTH- Funktion im Missionplaner auf einen Schaltkanal legen. Diese Funktion finde ich bei der Arduplane nicht. Kann wer helfen? Möchte den Flieger mit einem Schalter zurückholen können. Die Fernbedienung ausschalten ginge auch, aber möchte ich nicht...
Gruß
Reinhard
 

Yups

Erfahrener Benutzer
Besser spät als nie.
Schau mal im Log Browser nach, ob du I2C Error hast (PM -> I2CErr).

...oder mal ohne Verteiler anschliessen. Was hängt da noch mit dran? Der I2C Bus ist jedenfalls sehr störanfällig.

Hallo,
beim Copter kann ich die RTH- Funktion im Missionplaner auf einen Schaltkanal legen. Diese Funktion finde ich bei der Arduplane nicht. Kann wer helfen? Möchte den Flieger mit einem Schalter zurückholen können. Die Fernbedienung ausschalten ginge auch, aber möchte ich nicht...
Gruß
Reinhard

Geht bei Arduplane leider nicht, hab mich auch schon drüber geärgert. Da musst du dich Mischern rumplagen, um aus einem Kanal mehr als 3 Funktionen zu bekommen. Nicht sehr elegant finde ich.
 

Drohne

Erfahrener Benutzer
Hallo,
die Schalterbelegung/ Flugmodi gilt ja nur für einen Schalter. Ich möchte einen Schalter, der unabhängig von andern Stellungen immer RTH einschaltet. Keinen Mischer o.ä. So wie beim Arducopter oder FY 41...
 

AndreasL90

Erfahrener Benutzer
Verstehe ich das richtig: Du möchtest neben dem 1. Schalter, auf dem mehrere Flugmodi liegen, einen weiteren 2. Schalter, der den vom Schalter 1 ausgewählten Flugmodus abschaltet und mit RTH ersetzt?
 

DerFlash

Erfahrener Benutzer
Verstehe ich das richtig: Du möchtest neben dem 1. Schalter, auf dem mehrere Flugmodi liegen, einen weiteren 2. Schalter, der den vom Schalter 1 ausgewählten Flugmodus abschaltet und mit RTH ersetzt?
Richtig, so meint er das.

@YUPS: Beim Copter geht dies, beim Plane nicht.

Tipp / So mache ich es:

Bei meiner DX8 hab ich mit mehreren Mischern folgendes: FMODE & Mix Switch ergeben 5 Stellungen von 0-80% PWM für somit 5 Flight-Modes. Den 6ten, also 100% PWM erreiche ich wiederum mit dem GEAR Switch, was dann den von dir beschriebenen extra Schalter darstellt.
Das Ganze hab ich aber noch reversed, damit eben das RTL auf Flight Mode 1 einstellbar ist. Der "fest vergebene/nicht einstellbare" MANUAL Modus ist damit auch korrekterweise auf der Grundstellung (alles 0) meiner Schalter und es geht somit schön der Reihe nach:
GEAR=0 & MIX=0 & FMODE: MANUAL > STAB > LOIT
GEAR=0 & MIX=1 & FMODE: FBWA > FBWB > RTL
GEAR=1 & MIX=egal & FMODE=egal: RTL
 
Zuletzt bearbeitet:

Drohne

Erfahrener Benutzer
Mit den Mischer geht das natürlich. Aber ich mußte eben die Bereiche des Mode- Kanales total verstellen (nach dem Einlernen der Fernbedienung) Das macht das Ganze unübersichtlich. Freie Kanäle gibt es genug. Warum die nicht für sowas genutzt werden?
 

AndreasL90

Erfahrener Benutzer
APM:plane 3.1.0 ist verfügbar und bietet folgende Neureungen und Bug-Fixes:

Full list of changes in this release
  • added terrain following support. See http://plane.ardupilot.com/wiki/common-terrain-following/
  • added support for higher baudrates on telemetry ports, to make it easier to use high rate telemetry to companion boards. Rates of up to 1.5MBit are now supported to companion boards.
  • added new takeoff code, including new parameters TKOFF_TDRAG_ELEV, TKOFF_TDRAG_SPD1, TKOFF_ROTATE_SPD, TKOFF_THR_SLEW and TKOFF_THR_MAX. This gives fine grained control of auto takeoff for tail dragger aircraft.
  • overhauled glide slope code to fix glide slope handling in many situations. This makes transitions between different altitudes much smoother.
  • prevent early waypoint completion for straight ahead waypoints. This makes for more accurate servo release at specific locations, for applications such as dropping water bottles.
  • added MAV_CMD_DO_INVERTED_FLIGHT command in missions, to change from normal to inverted flight in AUTO (thanks to Philip Rowse for testing of this feature).
  • new Rangefinder code with support for a wider range of rangefinder types including a range of Lidars (thanks to Allyson Kreft)
  • added support for FrSky telemetry via SERIAL2_PROTOCOL parameter (thanks to Matthias Badaire)
  • added new STAB_PITCH_DOWN parameter to improve low throttle behaviour in FBWA mode, making a stall less likely in FBWA mode (thanks to Jack Pittar for the idea).
  • added GLIDE_SLOPE_MIN parameter for better handling of small altitude deviations in AUTO. This makes for more accurate altitude tracking in AUTO.
  • added support for Linux based autopilots, initially with the PXF BeagleBoneBlack cape and the Erle robotics board. Support for more boards is expected in future releases. Thanks to Victor, Sid and Anuj for their great work on the Linux port. See diydrones.com/profiles/blogs/first-flight-of-ardupilot-on-linux for details.
  • prevent cross-tracking on some waypoint types, such as when initially entering AUTO or when the user commands a change of target waypoint.
  • fixed servo demo on startup (thanks to Klrill-ka)
  • added AFS (Advanced Failsafe) support on 32 bit boards by default. See http://plane.ardupilot.com/wiki/advanced-failsafe-configuration/
  • added support for monitoring voltage of a 2nd battery via BATTERY2 MAVLink message
  • added airspeed sensor support in HIL
  • fixed HIL on APM2. HIL should now work again on all boards.
  • added StorageManager library, which expands available FRAM storage on Pixhawk to 16 kByte. This allows for 724 waypoints, 50 rally points and 84 fence points on Pixhawk.
  • improved steering on landing, so the plane is actively steered right through the landing.
  • improved reporting of magnetometer and barometer errors to the GCS
  • added FBWA_TDRAG_CHAN parameter, for easier FBWA takeoffs of tail draggers, and better testing of steering tuning for auto takeoff.
  • fixed failsafe pass through with no RC input (thanks to Klrill-ka)
  • fixed a bug in automatic flow control detection for serial ports in Pixhawk
  • fixed use of FMU servo pins as digital inputs on Pixhawk
  • imported latest updates for VRBrain boards (thanks to Emile Castelnuovo and Luca Micheletti)
  • updates to the Piksi GPS support (thanks to Niels Joubert)
  • improved gyro estimate in DCM (thanks to Jon Challinger)
  • improved position projection in DCM in wind (thanks to Przemek Lekston)
  • several updates to AP_NavEKF for more robust handling of errors (thanks to Paul Riseborough)
  • improved simulation of rangefinders in SITL
  • lots of small code cleanups thanks to Daniel Frenzel
  • initial support for NavIO board from Mikhail Avkhimenia
  • fixed logging of RCOU for up to 12 channels (thanks to Emile Castelnuovo)
  • code cleanups from Silvia Nunezrivero
  • improved parameter download speed on radio links with no flow control
Many thanks to everyone who contributed to this release, especially our beta testers Marco, Paul, Philip and Iam.

Happy flying!
 
FPV1

Banggood

Oben Unten