AQ hat zumindest im GPS Modus ein massives Softwareproblem

keilie

Erfahrener Benutzer
#1
Hier wiederhole ich meine Behauptung, dass Autoquad zumindest im GPS Modus ein massives Softwareproblem hat.

Ich habe ja schon länger und mehrfach die Vermutung geäußert, dass AQ ein Softwarefehler hat. Zumindest gibt es im GPS mode ein massives Problem, welches mich heute erneut ein Kopter gekostet hat.

Es ist wirklich schade, habe gerade begonnen mich in Quatos einzuarbeiten aber wenn elementare Grundfunktionalitäten nicht funktionieren mach das kein Sinn.

Das Problem im GPS mod ist, dass GPS Fehler, welche scheinbar unvermeidbar sind und welche mehr oder weniger häufig auftreten zu ungewollten Flugmanövern führen. Die unter Umständen bis zum Absturz führen.
Mag sein, dass es auch ein spezielles Hardwareproblem des M4 v2 Controlers ist, ein Deffekt eines einzelnen FC schließe ich aus, da das Problem mit allen 4 mir vorliegenden Exemplaren auftritt.

Das heute das GPS nicht besonders gut ist hätte ich vorher checken sollen.

2018-05-06_071414.jpg

Logs und Videos stelle ich bei Interesse gerne zur Verfügung.

VG Reiner
 
#2
Hier wiederhole ich meine Behauptung, dass Autoquad zumindest im GPS Modus ein massives Softwareproblem hat.

Ich habe ja schon länger und mehrfach die Vermutung geäußert, dass AQ ein Softwarefehler hat. Zumindest gibt es im GPS mode ein massives Problem, welches mich heute erneut ein Kopter gekostet hat.

Es ist wirklich schade, habe gerade begonnen mich in Quatos einzuarbeiten aber wenn elementare Grundfunktionalitäten nicht funktionieren mach das kein Sinn.

Das Problem im GPS mod ist, dass GPS Fehler, welche scheinbar unvermeidbar sind und welche mehr oder weniger häufig auftreten zu ungewollten Flugmanövern führen. Die unter Umständen bis zum Absturz führen.
Mag sein, dass es auch ein spezielles Hardwareproblem des M4 v2 Controlers ist, ein Deffekt eines einzelnen FC schließe ich aus, da das Problem mit allen 4 mir vorliegenden Exemplaren auftritt.

Das heute das GPS nicht besonders gut ist hätte ich vorher checken sollen.

Anhang anzeigen 173274

Logs und Videos stelle ich bei Interesse gerne zur Verfügung.

VG Reiner
Hmm ... wenn dem so wäre frage ich mich wieso meine Copter kein solches Phänomen zeigen. Kann daran liegen dass ich die ESC32'er grundsätzlich über CAN ansteuere (nicht per PWM), kann aber auch daran liegen dass ich erst mal dafür sorge dass der Copter im Manual Mode sauber fliegt bevor dich die Parameter für den GPS Modus tune.
 

sandmen

Erfahrener Benutzer
#3
@Reiner,
tut mir leid um deinen Copter.

Ich kann dir aber leider nicht wirklich helfen, da ich so ein Verhalten bisher nicht hatte, bzw. kein Problem damit habe.
Lade mal das Protokoll hoch.

Das es einen SW-Fehler gibt, das kann natürlich schon sein.....
 

keilie

Erfahrener Benutzer
#4
@Jörg, Peter: Wie sich das Problem genau darstellt bereite ich morgen mal auf. Das Protokoll lade ich auch hoch. Das ihr diese Probleme nicht habt, kann ich mir nicht vorstellen. Zumindest mit der FW die ich habe tritt der Fehler auf. Ich lade meine verwendete FW auch mal hoch. Kann ja wirklich sein, dass da ein bug drin ist.

EDIT: hier der Link zum Log und zu der verwendeten FW
https://www.dropbox.com/sh/g6m9bvcw6edhhs8/AABGAWr1xT8EAeWzsMqJK0ZVa?dl=0

Hier ein Ausschnitt aus der Zeit in der GPS_LAT und GPS_LON diese Sprünge aufweist.

GPS_LAT.jpg GPS_LON.jpg

An Position 309.985 ist der GPS Sprung von Lat: 50,95172 Log: 11,62231 auf Lat: 50,95163 Lon: 11,62227 - das sind ca. 10m.

Der Kopter folgt nun diesem Sprung von 10m. Ich denke das kann so nicht gewollt sein und kann in engem Gelände sogar gefähriche Folgen haben.

Das meine PIDs vieleicht noch nicht optimal eingestellt sind, sind ein anderes Thema und haben mit dem Grundsätzlichem Problem nichts zu tun.

Ich habe nun auch in anderen Foren diese Thema diskutiert und man ist der Meinung, das Empfangs Fehler im SBAS Korekturwert für diese Sprünge verantwortlich wären und die Software des FC dieses normalerweise herausrechnen würde.

Habe nun auch versucht, in AQ SBAS zu deaktivieren, was mir leider nur temporär gelungen ist. Ich denke AQ setzt SBAS immer wieder auf enable.

Wäre wirklich schön, wenn wir hier gemeinsam eine Lösung finden könnten

VG Reiner

Hier noch Impressionen vom morgendlichen Ausflug

IMG_7411.jpg IMG_7408.jpg IMG_7412.jpg IMG_7409.jpg IMG_7406.jpg IMG_7417.jpg IMG_7410.jpg IMG_7407.jpg
 
Zuletzt bearbeitet:

sandmen

Erfahrener Benutzer
#5
Was für ein ublox receiver hast Du den drauf ?
Siehe auf dem Receiver Typenschild.
Je nach dem, was für ein Receiver auf dem Board ist, wird eigentlich SBAS deaktiviert !
Siehe Code

static void ubloxVersionSpecific(int ver) {
if (ver > 7) {
// 5Hz for ver 8 using multiple GNSS
ubloxSetRate((uint16_t)200);
}
else if (ver > 6) {
// 10Hz for ver 7
ubloxSetRate((uint16_t)100);
// SBAS screwed up on v7 modules w/ v1 firmware
ubloxSetSBAS(0); // disable SBAS
}
else {
// 5Hz
ubloxSetRate((uint16_t)200);
}
}




Am Ende, kann man dem GPS "nur" trauen, wenn der GPS Receiver auch richtige Werte liefert.
Deswegen, haben wir eigentlich die "Genauigkeitsangaben" vom GPS hergenommen, die in den UKF ein gehen.
Somit sollten diese Sprünge, gefiltert sein. Das GPS-Lat & Lon ist das rohe Signal.
 
Zuletzt bearbeitet:

keilie

Erfahrener Benutzer
#6
Da ich nur M4 v2 Boards habe sollte da überall ein MAX-M8Q drauf sein - dann ist nach meinem Verständnis SBAS aktiviert.

Das mit den Genauigkeitsangaben vom GPS ist an besagte Stelle 309.985 auch kein Problem. GPS_HACC - verändert sich von 0,7725 auf 0,7820 und GPS_VACC bleibt konstant bei 0,9565 - das heißt für mich der UKF denkt alles mit dem GPS ist ok - das GPS ist aber nicht ok und der Kopter folgt dem falschen GPS Signal.

EDIT: habe in einem anderen Forum gelesen, dass ArduCopter ein ähnlichdes Problem vor zwei Jahren hatte und man da auch einiges tun musste um das Problem zuverlässig zu beheben.
 
Zuletzt bearbeitet:
FPV1

Banggood

Oben Unten