Funktionieren bei Euch Kompass und Baro vernünftig ?

[reinerdoll]

oh, entschuldigt bitte .. !

es ist genau wie vemutet : ich programmiere (als allgemeine vorbereitung für schulprojekte) eine fc von grund auf selber.es soll im wesentlichen um anwendung mechatronischer methoden gehen, also sensorik, regelungstechnik, signalverarbeitung, filter ...all das, was man braucht um copter zu spielen ! als sprache verwende ich luna, ich würds in c schon auch hinkriegen, aber die meisten "vorbilder" (z.b. mikrokopter") sind finde ich eher kryptisch programmiert, kaum kommentare usw..., find ich schwer zu lesen.

hw ist eine "baumarkt-mechanik" mit der fc von mikrokopter, dazu ein kompassmodul, ein gps und eine serielle funk-telemetrie, die später auch als steuermedium (+ laptop und joystick, aktuell aber mx12) dienen soll sowie eine "fpv-ausrüstung".

stand : das ding fliegt (ganz stabil sogar), ist gut steuerbar, hält den kompassgier sehr gut und auch der höhenregler arbeitet befriedigend (ich hab zwar schon bessere in youtube gesehen, aber 1/2 m toleranz schafft er). mir fehlt ein wenig die rückmeldung von außen, was andere so machen, deshalb mein beitrag oben.

beispiel gps : ("venus", theoretisch 20hz, bisher nur 1hz) nmea parsen ist ok, mit kompass auf nick/roll rechnen auch noch, aber der pid für ph ist mir unklar. ich hab hier ein pdf gefunden, da wird viel mit geschwindigkeiten (in m/s) als parameter gearbeitet, aber dafür hab ich doch gar keinen sensor. und acc (x/y) zu integrieren für fluggeschwindigkeit klappt bei mir sehr suboptimal;-)

irgendwelche flugbahnen als korrekturbewegungen programmieren ??

 

[Roberto]

@reinerdoll:

Wow, Respekt, dass hätte ich nie geschafft!!! Was kann ich tun, damit Du mithilfst, unser Mwii Leben zu verschöneren ?

Mit dem GPS kann ich Dir nur zeigen, was ich bis jetzt in dem Code gefunden habe.

"... da wird viel mit geschwindigkeiten (in m/s) als parameter gearbeitet, ..."
Die GPS Koordinaten werden als ASCII String übertragen und zunächst in Zahlen umgesetzt " nmea parsen" Abschnitt (GPS.ino):

////////////////////////////////////////////////////////////////////////////////////
// Utilities
//

Die Bewegungsgeschwindigkeit wird aus den Änderungen der Koordinaten/Zeit berechnet. Dabei wurde zuvor ein movingaverage Filter angewendet (ich meine 5 Elemente).

static void GPS_calc_velocity(){
  static int16_t speed_old[2] = {0,0};
  static int32_t last[2] = {0,0};
  static uint8_t init = 0;
  // y_GPS_speed positve = Up
  // x_GPS_speed positve = Right

  if (init) {
    float tmp = 1.0/dTnav;
    actual_speed[_X] = (float)(GPS_coord[LON] - last[LON]) *  GPS_scaleLonDown * tmp;
    actual_speed[_Y] = (float)(GPS_coord[LAT]  - last[LAT])  * tmp;
  
    actual_speed[_X] = (actual_speed[_X] + speed_old[_X]) / 2;
    actual_speed[_Y] = (actual_speed[_Y] + speed_old[_Y]) / 2;
  
    speed_old[_X] = actual_speed[_X];
    speed_old[_Y] = actual_speed[_Y];
  }
  init=1;

  last[LON] = GPS_coord[LON];
  last[LAT] = GPS_coord[LAT];
}

Theoretisch können sogar mit dem MediaTek PA6B, laut Datenblatt Geschwindigkeitsunterschiede von 0.1m/sec festgestellt werden. Selbst wenn man diese räumliche Auflösung schafft, ist die zeitliche Auflösung deutlich schlechter. D.h. die festgestellten Änderungen sind schon lange nicht mehr aktuell. Da könnte m.E das ACC für mehr Aktualität sorgen. Den auflaufenden ACC Fehler könnte man dann durch das GPS z.B 2x/sek kompensieren. Nur so eine Idee.

und acc (x/y) zu integrieren für fluggeschwindigkeit klappt bei mir sehr suboptimal;-)

Klar, da läuft schon nach wenigen Sekunden ein mega-Fehler auf.


LG
Rob

 

[weisseruebe]

Tja, bei Dunkelheit und Wind sich an einen neuen Höhensteuermodus zu gewöhnen, ist vielleicht doch die 2. beste Idee.

Du sagst es ;-) Das war sogar ziemlich dämlich...
Aber man muss schon sagen, das GPS hat sich damit rentiert. Ausserdem ist es für Luftbilder und für die eigene Sicherheit einfach genial, wenn der Copter selbst bei solchen Verhältnissen brav in seinem Korridor bleibt. Gerade war ich nochmal auf dem Heimweg zwei Akkus lang in Park. Böen lt. Wetterbericht von 6bft. (30-40km/h) werfen die Kiste zwar recht kräftig durch die Gegend, aber er kommt brav zurück und es ist kein manueller Eingriff nötig. Dolle Sache.

 

[reinerdoll]

so schlimm ist das nicht, regelungstechnik halt....
gerne würd ich hier ein wenig mitmischen, ich bin leider nur sporadisch aktiv, aus zeitgründen.

aktuelle "ziele" :

einmal das gps (mit ph und rth), wobei ich den hinweis auf die geschwindigkeitsberechnung über koordinatendifferenz schon sehr hilfreich finde.

und dann die serielle kopplung mit einem funkmodem (billigteil von pollin), wobei man das ding dann darüber erstens steuern könnte (mit nem joystick) und zweitens ein "blindflugcockpit" mit den lagedaten programmieren könnte. falls, und das ist die frage hier, falls die rechenzeit für diese gimmicks im labtop keine zu hohe latenz erzeugt !?!

 

[Roberto]

Vielleicht hilft Dir diese simpel navi - Anleitung etwas weiter: http://www.rcgroups.com/forums/attachment.php?attachmentid=1559067. Damit fliegt er wenigstens beim RTH ungefähr in Deine Richtung....
Für die Groundstation und Laptopgeschichte würde ich direkt eine mavlink - Standard kompatible Schnittstelle vorschlagen http://qgroundcontrol.org/mavlink/start. Dann bist Du direkt kompatibel zum APM Missionplanner, HappyKillmore GCS, QGroundControl u.a kompatibel. Ausserdem hast Du dann auch ein osd (MinimOSD). Die Einarbeitung würde sich in Deinem Fall lohnen, da Du Dir viel Programmierarbeit ersparst. Das wäre mir sogar noch einen "extra Arduino" als Umsetzer wert.
@weisseruebe: Ich bin leider noch nicht zum Mwii - GPS Fummeln gekommen. Aber bei der APM (ist sehr ähnlicher code) bin ich auch vom RTH begeistert. Hast Du eigentlich bei Deinen Testen auch solche Probleme wie bigbretl hier http://fpv-community.de/showthread.php?14199-Baro-Code-%C4nderungen&p=230822&viewfull=1#post230822 gehabt? Am WE kann ich wieder selbst testen.
LG
Rob

 

[reinerdoll]

... da bin ich mit meiner peilungsberechnung, (arc tan des quotienten aus lon und lat, genau wie im link in 4 quadranten betrachtet : genauso simpel) schon ganz nah dran, prima, danke für den link !

zur groundstation : das ist ein heißer tipp !!
ich wollte versuchen, das osd selber in vb .net zu schreiben, also das videobild quasi in eine windows-grafik mit den instrumenten wie ein "cockpitfenster" einblenden.
das geht mit der hardwarelösung natürlich 100 mal besser. trotzdem habe ich bedenken, ob eine "hud-grafik", mit künstlichem horizont und so (ähnlich einem hubschrauber-cockpit dachte ich mir) zu rechnen ist, ohne latenzen zu erzeugen die das steuern unmöglich machen. gibts da vorbilder ?
vor der kompatiblen schnittstelle (auch für diesen wertvollen link mächtig dank !) hab ich etwas scheu. ist schon ganz schön aufwand, wird aber unvermeidlich sein, wenn das hw-osd rein soll.... momentan koch ich ein eigenes süppchen, so hab ich z.b. den kompass hier auf süd = 0° normiert (wieso ? na : ich flieg in bayern !)

die baroprobleme von bigbrettl sind schwer übertragbar, weil mein regler ja wahrscheinlich ganz anders arbeitet.
meine probleme sind eher daß er bei bodenkontakt ziemlich aufschwingt und, noch schlimmer, daß das baby nach flottem vorwärtsflug im bremsvorgang ziemlich wegsteigt. wie ein flächenflieger oder auch ein hubi fast, obwohl aerodynamische effekte doch beim copter auszuschließen sind, oder ?

-> ohhhh, jetzt hab ich mir den "happy killmore" genauer angeschaut : das ist genau die variante, die ich mir gedacht habe. gibts schon, so ein mist. (umso mehr : danke für den link..)
das lohnt sich nicht, das nochmal zu erfinden, also : kompatible schnittstelle schreiben ...
ansatz : ich übertrag alle flugdaten "raw" nach unten, im laptop codiere ich nach mavlink oder so. wo finde ich "mavlink for dummies" ? ich benötige ja zunächst nur die positions / fluglage -daten, waypoints usw. sind noch unnötig.

 

[Roberto]

@ reinerdoll

bodenkontakt ziemlich aufschwingt und, noch schlimmer, daß das baby nach flottem vorwärtsflug im bremsvorgang ziemlich wegsteigt.

Bei Bodenkontakt kommt es zu ACC Fehlmessungen, deswegen ist momentan eine Landung ohne weiteren Filter nicht drin.
Deine Probleme im Flug klingen eher nach zu wenig hardware/software ("AccBaroLPF") LPF. Da kannst Du auf jeden Fall was machen! Evtl. ist auch das P etw. zu hoch.

Schön, dass Dir die Links etwas bringen! Die Sache mit dem MinimOSD bezieht sich auf die Onboardeinblendung in das Videobild (ASCII "Grafik"). Dein Plan, mit der Einblendung eines PC HUD in ein "gegrabbtes" Videobild geht z.B mit dem Missionplanner. Ich habe das noch nicht probiert, aber diese USB Grabber dürften eine unschöne Latenz produzieren. Probieren kann man es auf jeden Fall, die Dinger gehen schon für 10€ weg. Innerlich würde ich mich allerdings auf eine Videograbberkarte einstellen. Wichtig dabei ist, dass auch bei schlechtem Signal noch ein Bild kommt und nicht direkt ein "Bluescreen" eingeblendet wird. Bei Youtube gab es mal ein Video von einem Laptop-Missionplanner-Telemetrie-Joystickflug mit einem Flächenflieger. Der Pilot hatte anfänglich mit der Steuerlatenz zu kämpfen. Insgesamt kam da keine Begeisterung auf. Wenn Joystick, dann mit wenig Latenz über Trainerport o.ä. Hier mal ein Beispielprodukt: http://www.electronicarc.com/catalo...d=510&osCsid=f27dc1f134fa910039f4f5339333705c
Das gibts in China bestimmt für die Hälfte. Schade, dass sich da nicht das: http://www.reichelt.de/Kabel-Maeuse...8AAAIAAGZnqrs935d4b1b66581b04aa36ecd3cc6c1c71 anschliessen lässt (das Teil ist für Google earth der Knaller). Cool wäre natürlich ein Datenhandschuhsystem zum Steuern (v.a. im Winter, dann kann man direkt noch einen richtigen Handschuh drüberziehen)

LG
Rob

EDIT:
"nsatz : ich übertrag alle flugdaten "raw" nach unten, im laptop codiere ich nach mavlink oder so. wo finde ich "mavlink for dummies" ? ich benötige ja zunächst nur die positions / fluglage -daten, waypoints usw. sind noch unnötig. "

Schau Dir einfach den Sourcecode vom minimosd extra an, der ist übersichtlich, da dürftest Du schnell mit klar kommen.
http://code.google.com/p/minimosd-extra/
Die libs bekommst Du da oder z.B aus dem zip:http://code.google.com/p/arducopter/downloads/detail?name=ArduCopter-2.8.1.zip&can=2&q=

 

[bigbretl]

Hi,
ich habe es mit "Barocode Änderungen" schon geschrieben. Das mit dem Abschalten der Motoren kann an einem defekten Akku gelegen haben.
Gehe heute wieder Testen und berichte später.
Gruß bb

 

[Roberto]

@Bigbretl:

Hi,
ich habe es mit "Barocode Änderungen" schon geschrieben. Das mit dem Abschalten der Motoren kann an einem defekten Akku gelegen haben.

Das würde auch erklären, warum er nicht mehr steigen wollte.
Bislang habe ich den Fehler nämlich nicht reproduzieren können. Mit Baro (logic1&2) kann ich den Quad auf Vollgas bringen "MaxThrbaro" ("(MAXTHROTTLE-50)" das sind bei mir 1900).

LG
Rob

 

[reinerdoll]

was ist ein lpf ?

geraten : low-pass filter (also tiefpass) ...richtig ?

 

[Roberto]

Lowpassfilter, Genau!
Die meisten Mwii Sensoren haben schon einen 20Hz Hardware LPF aktiviert. Meistens reicht dieser für den ACC aus um die verbleibenden Vibrationen im Frame ausreichend zu filtern. Bei der MPU6050 ist der Hardwarefilter in der MWII primär ausgeschaltet, da nur ein gemeinsamer LPF für acc UND gyro definiert werden kann. Leider ist die MPU auch noch rel empfindlich, so dass es in den meisten Fällen nötig sein wird, den Hardwarefilter zu aktivieren ("MPU6050_LPF_42HZ"). Für den nicht unwahrscheinlichen Fall, dass das nicht ausreicht und man den Hardware LPF der MPU nicht weiter erhöhen kann um die mitbeeinflusste Gyrofunktion nicht zu beeinträchtigen, gibt es den optionalen "AccBaroLPF". Dabei ist ein Wert von 50 (d.h. 50%) ein guter Startpunkt. Ursprünglich sind wir hier auf dieses Problem durch Martinez aufmerksam geworden. Da der LPF die Amplitude des Nutzsignals verringert und eine Latenz produziert, kann man sich die Wirkung auch graphisch anzeigen lassen ("AccBaroDebug") damit man abschätzen kann, ob der gewählte Filter (in Prozent) ausreichend ist. Ein AccBaroLPF von 50 ist unbedenklich und eigentlich schon generell empfehlenswert, jedoch erhöht sich dadurch die Rechenzeit und der eeprom - Speicherbedarf (Programmgrösse). Ein AccBaroLPF von 100 (Prozent) kann man eigentlich wg der Nebenwirkungen (Latenz und verringerte Amplitude) vergessen, dann funktioniert es (bei mir) nur noch wie "Kaugummi". Ich habe aber die 100% von der Filterdefinition so gelassen, weil ich nur mit dem BMA180 flug - testen kann, und der hat schon einen 20Hz Hardwarefilter - vielleicht, mit einem ganz grossen Fragezeichen, könnten die 100% bei einer MPU, ohne eingeschlateten HardwareLPF, noch sinnvoll sein.


LG
Rob

P.s.:
Mehr zu dem Thema:
http://fpv-community.de/showthread.php?14199-Baro-Code-%C4nderungen&p=219720&viewfull=1#post219720

 

[JUERGEN_]

...,
jedoch erhöht sich dadurch die Rechenzeit und der eeprom - Speicherbedarf (Programmgrösse). Ein AccBaroLPF von 100 (Prozent) kann man eigentlich wg der Nebenwirkungen (Latenz und verringerte Amplitude) vergessen,

und da fragen sich Einige doch tatsächlich, ob ein 32Biter was bringt.

 

[reinerdoll]

da könnten wir ein großes faß aufmachen (..gerne, wenn du magst ;-).
hier liegen ein paar prinzipielle schwierigkeiten, die ich beim betrachten anderer copterprojekte habe. auch beim wii.

thema tiefpaß : wenn wir ein sensorsignal filtern, sagen wir mal 50 hz tiefpaß, hat die abtastung und regelung mit höherenfrequenzen als gut 100 hz doch eigentlich keinen sinn mehr. ich hab dazu versuche gemacht, die bringen genau dieses
ergebnis. ist ja auch imho kein wunder, wenn man mit ner wippe ein bodediagramm der nick- oder rollachse aufnimmt, kommt raus, daß schon viel früher (irgendwo zwischen 10 und 20 hz) schluß ist.
also schlußfolgerung : filter mit 50 hz über die sensoren (natürlich eigentlich ein hw-filter, shannon läßt grüßen !) und 100hz als zyklusfrequenz für die fc.

-> aber das sehen praktisch alle anderen (und die wissen sicher , wovon sie reden), anders. problem !

 

[Roberto]

Hi!
Diese theoretischen Überlegungen entziehen sich meiner beschränkten Kenntnis, aber Du darfst meine 50% nicht mit 50Hz verwechseln - das geht in keinem Fall auf!!! Ich habe den Filterbereich so dimensioniert, dass er einen praktischen Nutzen hat (Kurve ausgeben lassen und Bingo), und für normale Menschen, wie mich, mit einer Prozentzahl einstellbar ist. Bei der Mwii dürfte es sowieso sehr schwierig sein, definitive HZ Zahlen für irgend etwas anzugeben. Zum einen wird eine Vielzahl von Sensoren unterstützt mit bereits unterschiedlichen LPF (0-25 HZ) und zum anderen ist die Cycletime von der Sensorbestückung & seriellen Auslastung sehr unterschiedlich (ca 2xxx-4xxx us ohne "Spikes"), ausserdem wird nicht bei jedem cycle alles durchlaufen. Mit einer anderen CPU (Gruß, Jürgen!) oder mehreren CPUs könnte man sicherlich eine genauere Regelung, die theoretischen Überlegungen besser folgt, realisieren. Ich kann leider nur pragmatisch vorgehen. Trotz der offensichtlichen Hardwarebeschränkungen und des vielleicht zu unakademischen Ansatzes der Mwii, fliegt sie sich geil (sorry für den Ausdruck).

LG
Rob

 

[reinerdoll]

versteh mich nicht falsch .. ich kritisiere hier nix. im gegenteil : mit meinem "theoretischen ballast" komm ich ganz offensichtlich nicht so schnell und gut ans ziel. wenn ich mit anderen babys bei you tube vergleiche, fliegt mein apparat sehr suboptimal.(trotzdem liegt für mich der reiz in der anwendung der theorie .. und daß die dann fliegt. mach ja nix, oder ?)

zur frage von oben : was hältst du von 100 hz zyklus und 50hz sensorsignal ? ich teste grad 25hz (wegen dem bode ;-), und auch das fliegt sehr überzeugend .. ruhig und stabil. natürlich kein agiler kunstflug, aber das kann ich eh nicht steuern.

vorteil : bei der geringen zyklusfrequenz krieg ich massig luft in der rechenleistung für gps und serielle kopplung. und ich möchte eben keinen coprozessor draufbauen. grund ? ich habs gern spartanisch vielleicht. 32 bit und 3 coprozessoren find ich mädchenhaft. (entschuldigung gleich vorab an alle mit fettem prozessor und die frauenbeauftragte !!)

 

[Roberto]

Genau, 32 Bit ist was für Sitzpinkler & Turnbeutelvergesser (Nicht ernst gemeint).
"versteh mich nicht falsch .. ich kritisiere hier nix..." Ich hatte das auch nicht in den falschen Hals bekommen, aber Kritik ist wichtig, damit es konstruktiv weiter gehen kann.
So eine Fixed cycletime erledigt natürlich viele Probleme mit einem Schlag. Die Umsetzung bei der Mwii ist auf jeden Fall nicht einfach. Ich hatte das mal probiert (5000us fix d.h. 200Hz Loop - Verbrennen von Rechenzeit) nur leider knallte da bei vielen der serielle Port(BT/GPS etc) noch mit Spikes rein und die Sache war dann nicht mehr fliegbar. Timing scheint mir bei Multicoptern sowieso essentiell zu sein bis herunter zum fertigen PWM Signal. Wenn man mal eine neue FC/Software entwerfen sollte, sollte man im Ablaufplan das an erste Stelle setzen, das dürfte hinterher viel Kummer ersparen. Eine Lösung wäre m.E eine Art Double oder Tripple buffer, wie bei den Grafikkarten. Das frisst natürlich Speicher und eine zügige Abarbeitung schadet da nicht. Dann kommen natürlich noch die Sensorlatenzen dazu. Für mich ist das unüberschaubar. Deine angepeilten 10ms (100Hz) stellen sicher die Obergrenze dar.
Ein reines Verbrennen der Rechenzeit bringt es leider nicht, Du müsstest schon vorhersagen, wie lange der nächste Durchlauf wahrscheinlich brauchen wird, damit das sinnhaft wird.

LG
Rob

 

[reinerdoll]

buffer ?? wie geht das ? (jetzt übertragen auf den 8bit uC..)
genau das problem hab ich natürlich, daß der rc-decoder mit seinem interrupt in den schönen zyklus reinzickt.
das ist einer der gründe, die für serielle steuerung sprechen : dann brauch ich keinen pwm-decoder ;-)

 

[Roberto]

Im Prinzip wie hier: http://de.wikipedia.org/wiki/Doppelpufferung.
Damit kann man im Prinzip schwankende Rechenzeiten ausgleichen und eine gleichmässige Ausgabe erzielen. Wie man das jetzt praktisch umsetzen kann, bin ich natürlich überfragt. Vielleicht ist es sinnvoll alle (I/O) Rechenzeitzicken auf einen Extraprozessor zu verbannen. Die Ergebnisse werden dann über den Hauptprozessor, in festem Abstand, aus dem Pufferspeicher geholt.
Ich glaube wir sind hier weit OT.

LG
Rob

 

[JinGej]

...oder einen prozessor verwenden, der sich langweilt....

 

[reinerdoll]

ot ? eigentlich schon, aber prozessorfragen sind ja in jedem thema hier drin ..

auch ein prozessor, der sich langweilt, hat das problem, daß der externe pwm-zyklus (kommt ja aus dem steuersender) mit dem internen regelzyklus asynchron läuft. und das gibt unweigerlich probleme ...

außer : man synchronisiert die fc nach dem pwm-zyklus, was schwierig ist, weil die rate dann sehr hoch sein muß.
ich machs so : alle seriellen und i2c - kommunikationen (brushless, kompassmodul) synchronisiere ich mit der pwm. beim regelzyklus lass ichs drauf ankommen, und bemerke auch dann und wann einen störspike im flug.
langfristig ist denke ich serielle steuerung das optimale ....