NAZE32 - alternative Software

[JUERGEN_]

..apropo OSD
altes ist selten tot zu kriegen, OSD Konnte man schon nur mit einem AVR alleine

mit ner Propeller-CPU wude dann eine feinere Grafik möglich, als mit den vordefinirten TV-Zeichensätzen.

-> http://www.armokopter.at/forum/viewtopic.php?f=19&t=128

so etwas ist für einen STM32 auch erst recht kein Problem.

 

[Roberto]

@Bamfax: Danke für den Hinweis!!!! Ich musste nämlich grade feststellen, dass man nicht so einfach das serielle Protokoll wechseln kann. Total aufgepumpt eben, für ein einfaches osd vollkommen daneben.
@Jürgen: Genau! Ich verstehe sowieso nicht wo das Problem ist. Ein Grafikchip, der eine einfache, double buffered, Bitmap in 800x600 verwalten kann und autonom Linien Ziehen kann, gibts doch schon länger als 30 Jahre. Diese STM und Propellersachen will ich einfach nicht verstehen, wo eine CPU dazu missbraucht wird, einen Vsync zu erkennen und den Bildschirm selbst aufzubauen und zu verwalten. Da darf man sich dann programmtechnisch durchs Knie schiessen, damit nichts flackert usw. Das nenne ich mal einen echten, technologischen Rückschritt vom Feinsten.

LG
Rob

 

[JinGej]

...machts nich so teuer

 

[Daddy_Walross]

Ich habe leider keine Zeit mir die ganzen Links durchzulesen, aber die Hardware scheint mir recht simpel. Hier können wir uns auch gerne selber was zurechtstricken, sobald wir 10-20 Leute zusammen haben wird's dann auch sehr günstig.

Und weil ich gerade zu faul bin zu suchen, gibt es irgendwo schon fertigen Code, wo Leute Daten von der FC an den FrSky Empfänger geben?

 

[Roberto]

Hast Du schon mal dort geschaut: http://www.multiwii.com/forum/viewtopic.php?f=7&t=1929 ?

 

[Bamfax]

Ich versteh zwar nicht was Jürgen wieder redet, aber nach Rob's übersetzung dann doch wieder ein bisschen. Anscheinend brauchen wir doch mal ein zeitgemäßes OSD . Also Daddy, wenn Du wieder eine quasi handsignierte Community-Platine, diesmal für ein OSD, entwirfst, dann bin ich mit Sicherheits dabei. Auf der anderen Seite, wenn Carsten schreibt, dass er den Afro-Prototyp schon aufm Tisch hat, dann könnt man das evtl nochmal abwarten.

 

[Daddy_Walross]

Danke Roberto, ich wusste ihr könnt mir helfen! Das ist doch sehr interessant, werde ich nach dem Sonar mal angehen. So little time... aber es kann in der GUI schomal ein Feature FrSkyTelemetrie vorgesehen werden
P.S. Ich Döddel seh gerade, dass hat tc ja schon fertig! Muss ich ja glatt mal ausprobieren die Tage...

@Bamfax: So eine Platine habe ich schnell fertig und ich organisier das auch gerne. Aber wenn tc was hat, dann sicher sehr günstig. Nur bisher rückt Carsten ja keine Infos über die HW raus

 

[JUERGEN_]

Telemetrie FrSky Empfänger

der FrSky Empfänger verlagt ein Invertiertes Signal.

bei einigen NAZE32 hat TC ja den Inverter ja beigepackt ?

allerdings habe ich nicht in der Software eine Aktivierung für FrSky-Telemetrie gesehen ?

 

[Komma]

@ Roberto

Wie siehts eigentlich mit der Magnetokompaßkalibrierung aus, ist das jetzt schon State of Art?
Oder arbeitest du noch dran.

Cheerio

 

[Roberto]

@ Roberto

Wie siehts eigentlich mit der Magnetokompaßkalibrierung aus, ist das jetzt schon State of Art?
Oder arbeitest du noch dran.

Cheerio

Hi, Komma!

Ich weiss nicht, ob sie state of the art ist, aber die Kalibrierung betrachte ich erstmal als fertig, da das Ergebnis sehr brauchbar ist. Mittlerweile habe ich die Auswertung des Mags auch in jeden Durchlauf gezogen, wobei das Mag dadurch deutlich prompter reagiert. Das ist wichtig für die ACC Integration. Ausserdem habe ich im Hauptprogramm noch ein paar suspekte Mag Zeilen aufgespürt und auf Datentyp float umgestellt, das erscheint mir sinnvoller. Und einen zusätzlichen Variablen reset z.B
Original:

...
                GPS_reset_nav();
            } else {
                float sin_yaw_y = sinf(heading * 0.0174532925f);
                float cos_yaw_x = cosf(heading * 0.0174532925f);
                if (cfg.nav_slew_rate) {
...

Jetzt:

...
                GPS_reset_nav();
                GPS_angle[ROLL]  = 0;
                GPS_angle[PITCH] = 0;
            } else {
                float headradtmp = heading * RADX;
                float sin_yaw_y = sinf(headradtmp);
                float cos_yaw_x = cosf(headradtmp);
                if (cfg.nav_slew_rate) {
...

Das kommt in der nächsten Version.
Mittlerweile bin ich nicht mehr so auf den neuen APM gps/ins code gespannt, der wird wahrscheinlich auch noch voller neuer Fehler stecken.

LG
Rob

 

[JinGej]

also:...
ich habe heute mit der 07c - also der letzten version, wo acc (hab ich auf 0.5 gestellt) mit bei gps drin ist - getestet - als ich dann endlich 7-8 satelliten hatte, hab ich einen test gemacht - der copter wollt auch gleich mal nich auf der stelle bleiben und fing an einen riesen kreis zu machen mit aggressiven manövern - abbruch... dann mag nochmal MAG kalibriert (nächster akku) - noch ein test - da blieb er auf der stelle, driftete aber langsam aber sicher immer weiter ab... nach ca 20m abdriften hab ich wieder aufgehört.... - dann wieder nächster akku... noch ein test (nix verändert) und nun wollte er wieder abhaun und riesen kreise machen... ich weiß nicht was da nicht stimmt...
Gruß,
Jin'

 

[Roberto]

@JinGej: Danke erstmal für Deinen Test! Mittlerweile denke ich, dass die fehlende Floatumwandlung/Behandlung des headings auf dem STM Probleme macht. Ich habe grade hinter dem Haus, wo normalerweise nix geht mit GPS, einen PH Test gemacht (MTK1.9) und es funktionierte mit noch rel grossen Kreisen (Harakiri"7d" und gps_ins_cf 0.9). Da geht noch was! Ich wollte mir heute den ganze gps schei** nochmal in Ruhe anschauen. Also JinGej nicht verzagen, irgendwann läufts ...
Hast Du mal ein gps_ins_cf von 0.5 oder mehr probiert? Wenn nicht, warte mal auf die nächste Version....

LG
Rob

 

[JinGej]

ich habe nur 0.5 probiert und wie gesagt einmal machter kreise mit aggressiven kurven und einmal stehter wie angenagelt - aber driftet dabei ganz langsam

 

[Roberto]

Die 20 m machen mir eher Sorgen das riecht nach failcode. Die langsame Drift ist eigentlich noch ok, aber sollte irgendwann korrigiert werden, wenn er wieder eine andere GPS Position bekommt. Das driften kommt u.a durch meinen ACC "cutoff" von 80 (8%) d.h. unter diesem Wert werden ACC Werte ignoriert und als Rauschen/etc interpretiert. Die "80" ist nur auf dem Schreibtisch ermittelt. Vielleicht könnte man den zweiten ACC auch auf dem Naze aktivieren um so das Gesamtrauschen zu minimieren, also die ACC Daten des einen mit dem Anderen vergleichen. Der eine Zeigt eine Bewegung nach rechts, der andere nach links (bei gleichem Scaling), dann komplementärfiltert man beide Werte und gibt dann das Ergebnis als halbwegs vertrauenswürdig weiter...
Hmmm...
Als nächstes schraube ich den Vergaser auseinander und reinige die Düsen - ähem, ich meine die GPS PID Kontroller....

P.s.:

Hallo Freunde der NAZE 32,
ich habe eben mal mit der "Haustechnik" gemailt...
Er kümmert sich morgen drum, daß der entsprechende Beitrag editierbar wird/bleibt!
Heute klappt es, wegen physischer Abwesenheit, leider nicht mehr...

Gruß
mueckchen - der hier eh immer mitliest, aber beim Thema Software nix zu sagen hat!

Bis jetzt gehts noch nicht - der Hausmeister hat wohl Urlaub?

LG
Rob

 

[JinGej]

gut - ja ich glaub da ist noch was faul... weil, mal gehts schön (2x) und mal gehts garnich (2x) (die aggressiven kreise) und das innerhalb 3 akkus

 

[Roberto]

Eigentlich müsste der ganze GPS Teil neu durchdacht und geschrieben werden. Da steckt auch noch zuviel Flugzeuglogik drin, die beim Copter eben so nicht passt und nur rein gepatcht ist. Ein Flugzeug fliegt selten rückwärts. Ausserdem werden Lat/Lon zu häufig getrennt betrachtet, statt eines relevanten Bewegungsvektors. Die ganze Crosstrack - Sache ist m.E auch eher für Flugzeuge u. Autos relevant, weil die eben nicht so momentan ihre Richtung ändern können, sondern immer einen Bogen fliegen/fahren müssen. Das kann ja heiter werden.
LG
Rob

EDIT: Ich glaube, jetzt habe ich die Nuss geknackt - der Testflug eben war verdammt Naza verdächtig, und das nur mit einem MTK. Ich werde mal meinen Cut off für das Acc ganz rausnehmen, mal sehen. Der clou war, die acc Werte (cm/s) wieder in GPS LAT/LON Werte zurückzurechnen (Position in Grad) und damit kontinuierlich die GPS Schleife laufen zu lassen und nicht nur 5 mal in der Sekunde bei neuen GPS Daten. Das ist Quasi der Leadfilter deluxe, da keine Zwischenwerte erraten werden müssen (auf Basis älterer), sondern echte Zwischenwerte vorliegen. Mal sehen, das riecht nach Harakiri08.

EDIT: So, beim Zurückrechnen ist endlich mal eine Division durch NULL aufgetreten - weil nämlich eine Variable eben manchmal nicht initialisiert wird (Faktor für longitude - Skalierung). Das dürfe auch bei Dir, Jingej das Problem gewesen sein, weil dadurch falsche Koordinaten zustande kommen und Dein Copter Richtung Pazifik unterwegs gewesen sein müsste. Die Initialisierung wurde nämlich zu spärlich gehalten, jetzt frage ich einfach den Zustand der Variablen vor Verwendung ab, ist sie nicht initialisiert, wird das erledigt.

 

[JinGej]

yaaay!
seeehr schön, ich seh schon... das wird ein NAZA killer

danke für die super arbeit!

 

[LordWimsey]

"gefällt mir"

 

[JollyJoker]

Die aktuell empfangene Satanzahl wird durch Blinken der roten LED angezeigt (ab 5 Sats, d.h. blinkt nicht z.B bei 4 Sats). Sinn: Sobald man den copter scharf schaltet, wird die Homeposition gespeichert, die ab 7 Sats auch brauchbar genau ist. Wenn man z.B bei nur 5 Sats startet, muss man sich bei einem RTL nich wundern, wenn er 20m weiter weg landet. Es wird immer ein "Block" geblinkt, dann werden 1,5 Sek Pause gemacht, dann wird wieder der "Block" Satnummer zum Mitzählen geblinkt.

Kann es sein, das die Blinkimpulse von der eingestellten LoopTime abhängen? Wenn ich die auf 3000 stelle, blinkt es sobald POS_HOLD oder RTL eingeschaltet ist so schnell, das ich gar keine Chance habe mitzuzählen zwischendurch dann mal ein deutliches leuchten, dann habe ich mal mit 2500 probiert, und da ist dann dauerhell mit kurzen Unterbrechungen in denen geflackert wird. Auf Wunsch mache ich nen Video

Da mein GPS gerade fürchterlich abnervt würde ich da auch gern noch mal Klarheit haben.

Gruß Peer

 

[LordWimsey]

Die empfangene Satan-Zahl ist immer 666 und kann durch schnödes LED-Blinken nicht abgebildet werden...

EDIT:
Ich habe eine graue Vermutung:
Wahrscheinlich hat Dein Modul noch nicht genügend Satelliten gefixt. Die LED blinkt eigentlich permanent mit 10Hz, also der Abfragerate des GPS-Moduls.
Die Anzahl der gefixten Satelliten werden so angezeigt:
- blinkt/flackert f*k*ng schnell mit 10Hz, eine Weile lang.
- kleine Pause im Flackern
- flackert (1)
- kleine Pause im Flackern
- flackert (2)
- kleine Pause im Flackern
- flackert (3)
- kleine Pause im Flackern
- flackert (4)
- kleine Pause im Flackern
- flackert (5)
- kleine Pause im Flackern
- blinkt/flackert f*k*ng schnell mit 10Hz, eine Weile lang.

in dem Beispiel würde die Mindestanzahl von 5 Sats angezeigt. Bei <5 flackerts einfach in einem durch.

EDIT2:
Oder überlagert das mit GPS-Funktionen automatisch eingeschaltete ACC das Blinken?
Ich kann meine Sats zählen, wenn ich weder PH noch RTL eingeschaltet habe. MIT PH oder RTL hab ichs noch nicht probiert.

Ich hatte mit dem u-Blox CN-06 Modul auch so meine Problemchen und habe ewig mit dem u-center rumgehext, Lösung war, dass das Programm, dass ich benutzt habe, den GPS-Type nicht umgestellt hatte, obwohl es das sollte. Auch die Baudrate (GPS_Baudrate) wurde nicht gespeichert.
Ich habe diese zwei Parameter dann mit Putty eingestellt, (Feature GPS ist enabled?) dann liefs gleich prima.

Zusammenfassung (wie es am Ende bei mir geklappt hat):
- feature gps einschalten (das ging mit dem Naze32Configurator von Nicogh)
- gps_type über cli einstellen (bei ublox auf 1, das ging NICHT mit dem Configurator, habs dann mit Putty gemacht: "set gps_type=1")
- gps_baudrate über cli einstellen (ging auch nicht mit dem Configurator, Putty: "set gps_baudrate=115200")
- die Konfiguration in Putty nochmal gespeichert, Board neugestartet (Putty: "save")

Das wars eigentlich. Die Firmware setzt das GPS-Modul bei jedem Start wieder auf die gewünschten Werte und Bob ist Dein Onkel.

Hoffe, das hilft vielleicht.


Grüße,
Peter