Funktionieren bei Euch Kompass und Baro vernünftig ?

Hallo,

ist es denn nicht auch möglich mit aktiviertem Alt-Hold den Code so zu machen, dass der Copter nicht mehr direkt über "throttle" mit dem Gasknüppel sondern über die "Stellung" des Gasknüppels gesteuert werden kann... also ich mein' Gasknüppel mitte ist genaue höhe halten, wenn man den nach unten bewegt heißt sinken mit einer bestimmten definierten und dauernd gemessenen rate abhängig von der knüppelstellung - z.b. 0....3m/s genauso zum steigen -- so dass man dem copter eben über den gasknüppel eine sink/steig rate (die in der mitte 0 ist) einfach vorgibt und nich einfach nur gas gibt oder wegnimmt?
Gruß

Ich muss mich auch noch mal melden, kriege langsam graue Haare (na ja, paar sind schon lange da). Hab gerade noch mal die Sache mit dem MAG getestet. Es ist bei mir wirklich so: Giere ich manuell minimal nach links oder rechts, dreht sich nach loslassen des Hebels der "Schraubhuber" wieder zurück. Steuere ich richtige Kurven, bleibt das Teil auf dem neuen Kurs wie angewurzelt. Ist das so gewollt (meinetwegen für zittrige Anfängerfinger, oder muss ich noch was an den MAG-Werten schrauben. Würde mich jetzt mal echt interesieren. Mal davon abgesehen ob's so nicht sein darf, empfinde ich diese Reaktion gar nicht mal so übel, da man in der Hecktik mal schnell am Gierhebel wackelt, auch wenn's nicht sein soll. Dadurch dreht der Quadro bei übereifriger Gieromanie wieder aufs Fotoobjekt. Wie auch immer, wie isses denn nun richtig und gedacht? Do Sachse sagt . . . Ich wär bald blede . . .

Tschüss, Micha

Hallo Micha,

so wie es aussieht mußt du etwas größere Bewegungen am YAW Knüppel machen damit der Kopter sich die neue Lage merkt.

Gruß Willi





#if MAG
if (abs(rcCommand[YAW]) <70 && magMode) {
int16_t dif = heading - magHold;
if (dif <= - 180) dif += 360;
if (dif >= + 180) dif -= 360;
if ( smallAngle25 ) rcCommand[YAW] -= dif*P8[PIDMAG]/30; // 18 deg
} else magHold = heading;
#endif

Hallo Willi,

danke für deine Hilfe. Im Code steht genau das. Wie gesagt, diese "Variante" ist eigentlich nicht mal schlecht. An die größeren Yaw-Wege gewöhnt man sich fürn Rundflug recht schnell.

VG Micha

Ich finde auch, dass das so passt.

Na prima, dann pack ich jetzt den Deckel wieder drauf und rüher das Teil erst mal nicht mehr an (im Inneren), es sei denn, morgen kommts von alleine etwas zu steil und schnell von oben zurück, da steckt man ja nicht drinne

Also, ich dank euch allen wie verrückt, bis später . . . sonst wird mein Feldschlösschen-Pils warm . . .

Micha

@Helste: Danke für die Blumen!
Ich habe jetzt 2 Projekte.
1.: Ich sehe noch eine Möglichkeit, die Modifikation noch etwas zu verbessern
Der Vorteil ist: Sie ist sehr nahe am Original und ändert nichts Entscheidenes, daher leicht anpassbar, hohe Betriebssicherheit.
Der Nachteil: Ist bekannt.
2.: Beim rumgooglen bin ich auf die Modifikation von "alexmos" gestossen (http://code.google.com/p/multiwii-alexmos/).
Er hat genau dass gemacht, was wir alle wollen! Er hat den ges Baro PID Controller neu geschrieben und errechnet noch einen vertikalen Bewegungsvektor aus den ACC Daten und gleicht diese mit den Barowerten ab! Ausserdem verwendet er noch ein Sonar für geringe Höhen. Ich werde versuchen, den Alexmos code von dem Sonarcode zu befreien und in die aktuelle Dev einbauen. Das geht an die "Eingeweide", also nicht mehr so harmlos wie bisher. No risk, no fun, vielleicht werde ich nicht nur mit kaputten Propellern, sondern auch mit einem guten Ergebnis belohnt.

@JinGej: Natürlich ist das möglich - programmier es endlich, denn ich kann es nicht.

LG
ROB

Reagieren diese einfachen Baros wie ein BMP085 wirklich so penibel auf Luftdruckänderungen, dass es sich lohnt diese Mühe zu machen? Ich habe da so meine leisen Zweifel . . . Die Frage ist durchaus ernst gemeint.

LG Micha

Die Antwort ist ganz klar: JA, das kannst Du am NAZA bewundern.
Die Baros BMP085 und MS561101BA sind sehr empfindlich. Der MS561101BA ist neuer, genauer und liefert nicht soviel Datenschrott wie der ältere BMP085. Im aktuellen MWII Code lässt sich die Datenaufbereitung verbessern und die Integration mit den zur Verfügung stehenden ACC Daten findet überhaupt noch nicht statt. Ich frage mich nur immer, wie der Baro bei X Propellern in unmittelbarer Nähe noch einen anständigen Luftdruck liefern kann. Bei den NAZA aufschraube-Bildern sieht man immer, das der Baro (MS561101BA) vollkommen eingekapselt ist. Da ist kein extra Luftloch im Gehäuse. Vielleicht sollten wir uns da mal Gedanken drüber machen, ob wir unsere Baros nicht auch besser kapseln sollen?

EDIT: Laut Datenblatt soll der BMP085 0,03hPa (0,25m) Unterschied im "Ultra high resolution Mode" feststellen können. Soweit ich weiss, wird bei der Multiwii dieser Modus nicht verwendet, sondern nur der 0,5m - Modus.

Mit sowas: http://www.neckermann.de/Barometer ...d.html#barometer-messing&ia-pmtrack=175601990
kann man auch einen Althold bauen - Schleifkontakte an den Zeiger und los gehts

OK, meine Infos beziehen sich dann auf die älteren Typen der 085er. Das mit dem Abkapseln ist wirklich so. Habs aus Neugier einfach mal ausprobiert. Einfach Deckel weggelassen und hoch, hatte zum Glück schon den Notausschalter eingebaut. Es war ein ständiges auf und ab und Landen mit Baro fast nicht mehr möglich . . . In einem hallwegs abgeschotteten Dom sollte es aber auch ohne "Schwamm" einigermaßen klappen. Probieren geht auch hier über Studieren! Also, viel Spaß beim "Docktern", wenn du es hin bekommst, dass statt +/-1m nur noch 20cm übrig bleiben, wirst du hier zum Helden, versprochen

VG, bis dann, Micha

Das Gehäuse der Naza ist jedoch alles andere als luftdicht. Bedingt durch die mehreren zusammengesteckten Teile kann man förmlich durch das Gehäuse durchblasen. Dass es nicht ganz ohne Luftdurchlass geht, zeigt insbesondere das Wookong: Da hier keine Stiftleisten herausgeführt sind und dadurch deutlich weniger Öffnungen vorhanden sind, hat das Gehäuse eine ganz kleine Bohrung für den Druckausgleich.

Vermutlich ist es letztendlich eine Frage guter Dämpfung. Beide DJI-Systeme sind diesbezüglich auch noch nicht das Nonplusultra: Bei relativ ruhigem Wetter stehen beide wie eine Eins in der Luft, doch bei beiden habe ich stärkere Höhenschwankungen bei Windböen festgestellt.

Schnelle Schwankungen werden noch sehr gut ausgeglichen, da hier vermutlich die Z-Werte des ACC mit einberechnet werden können. Frischt der Wind jedoch einfach langsam auf, kann es zu einer Höhendifferenz von mehreren Metern kommen. Ich bin zumindest beim Wookong der Meinung, dass es abhängig von der Position zum Wind ist. Das ließe sich dadurch erklären, dass je nach Winkel von Bohrung zu Wind entweder ein ganz leichter Unter- oder Überdruck im Gehäuseinneren entstehen kann. Wenn diese Mutmaßung zutrifft, dürfte eine Dämpfung mittels Schaumstoff das bessere Ergebnis bringen.

. . . dürfte eine Dämpfung mittels Schaumstoff das bessere Ergebnis bringen . . . Vollste Zustimmung, allerdings ist mir das Höhe halten ziemlich Wurst, wenn starker Seitenwind das Fluggerät ins nächste Gebüch befördert Ist irgendwie alles rellativ zu sehen . . .

Gute Nacht an alle, bis morgen

Micha

wenn die Kapsel dann nur 1 Luftloch hat, hast du genau das gleiche wie Vorher, nur grösser.

es geht hier doch nicht ums Kapseln, sondern um Diffusor, der Luftstrom ist so zu verteilen,
das sich kein Staudruck ( = Fehlmessung) an der Messöffnung bilden kann.

an einem Mikrofon verwendet man so etwas, um Windgeräusche zu minimieren.

Danke Jürgen, genau nach dem Begriff hatte ich gesucht, denn er erklärt alles.

Roberto, wenn Du den Sonarcode entfernst, dann mach das bitte so, dass man ihn leicht wieder aktivieren kann.
Ich habe am APM1 ein Sonar montiert und das ist wirklich genial. Das könnte man später mal auch am Multiwii probieren.

Was die Verpackung des Baro anbelangt, so habe ich da ein Stück Schaumstoff drüber geklebt und bei mir ist das gesamte Board in einer geschlossenen Box montiert. Da sind nur kleine Öffnungen um die Kabel durch zu führen. Ich kann ja mal testen, ob es einen großen Unterschied macht, ob ich den Deckel auf lasse oder ihn schließe.
Leider gibt es bei uns seit ca. 2 Wochen kaum einen Tag ohne massig Wind. So ist es halt immer relativ, was beim Test raus kommt. Alle meine bisherigen Versuche der letzten Tage fanden bei ziemlich heftigem Wind statt. Dafür bin ich mit den Ergebnissen eigentlich zufrieden.

Ich habe jetzt mal die alexmos Version drauf getan. Funktioniert auch sehr gut. Leider halt wieder sehr windig und daher kein aussagekräftiges Ergebnis, was die Stabilität anbelangt. Von der Steuerung her ist das aber schon sehr gut. Wenn Baro aktiviert ist, dann tut sich gar nix, wenn man den Gasstick bewegt, bis man über einen bestimmten Bereich raus kommt. Dann geht er rauf oder eben runter, jenachdem. Gefühlsmäßig ist das so wie beim APM1 nur halt mangels angeschlossenem Sonar nicht so präzise bei geringer Höhe. Mit dem Sonar am APM1 geht Kopter wirklich auf ein paar cm genau und folgt dabei auch dem Gelände.

Wo muß ich da draufgehen um den Code runter zu laden? Ich komme immer wieder auf die selben Seiten.

Gruß Paraglider58

Einfach dem Link folgen und da dann auf downloads gehen.

hahaha ok, dann sind wir schon 2

@r0sewhite:
Ich Danke Dir, das sind für mich wichtige Erkenntnisse!

@JUERGEN
Ohne es jetzt technisch so treffend ausdrücken zu können wie Du, etwas in der Art hatte ich gedacht.

Wenn man beide Informationen zusammenfügt, könnte es dann nicht THEORETISCH u.U sinnvoll sein, den ganzen Sensor in einem annähernd runden, luftdichten Gehäuse zu verpacken - quasi in einem dünnwandiges Ü-Ei und gut zugeklebt? Das hätte den Vorteil, dass die Windangriffsrichtung egal ist und den Nachteil, dass die kompressible Luft in dem "Gehäuse" eine Latenz produziert und die Sensorauflösung verschlechtert. PRAKTISCH scheint es witzlos zu sein, sonst wäre es bei NAZA/WOOKONG umgesetzt worden.

Zurück zum Code:
Projekt 1 (http://fpv-community.de/showthread....o-vern%FCnftig&p=148465&viewfull=1#post148465) ist nach meinem Ermessen fertig und funktioniert nach meinem Ermessen gut (da kommt noch ein Post...).

Die Alexmos Variante basiert leider auf einer alten MWII Version, ist aber von der Intelligenz her dem original Code um Meilen voraus. Am besten warten wir, bis er eine neue Version bringt (ich bin aber dran!)

Das bringt mich schon zum nächsten Teil:
Kritik, aus meiner Stümpersicht an der aktuellen Entwicklung des MWII Projektes:
Jeder, der den aktuellen MWII Code compiliert, wird sehen, dass nur noch ca 7KB frei sind. Jeder, der selbst Veränderungen vornimmt sieht, wie schnell die 7KB dahin schmelzen können. Statt die aktuellen Funktionen zu debuggen oder zu verbessern (siehe Alexmos) werden Zeit, Man(&Woman?)power und wertvolle Bytes auf GPS,Heli und Airplane verschwendet. Wenn dass so weiter geht, ist MWII m.E am Ende. Der Prozessor ist nicht langsam, aber der Speicher ist stark begrenzt. War der Urgedanke nicht, dass man mit wenig Hardwareaufwand solide Multicopter fliegen kann? Und an dem soliden Fliegen kann es bei neuen Sensoren und "exotischen" Setups wie Tri oder Hexa schon scheitern (Hexabug oder http://www.multiwii.com/forum/viewtopic.php?f=8&t=1736). Wer jetzt GPS/AIRPLANE/HELI/Waypoints braucht, greift nach bereits fertigen Lösungen - zumindest würde ich das so machen. Warum sind eigentlich alle so begeistert über den AQ50d? Der kann nur ACC - aber offensichtlich gut! Sollte denn die Multiwii nicht wenigstens den ausstechen können? Ich meine, es ist Zeit über eine komplett andere Hardwareplattform nachzudenken mit deutlich mehr Speicher und Rechenleistung. Wenn alle Bewegungs, Höhen und GPS Vektoren berechnet und integriert (incl. Waypoints ) und auf alle Plattformen vom Auto bis zum Xoctocopter umgesetzt sind, was bleibt denn noch? Klar, die visuelle Datenverarbeitung. Z.B: Erkenne eine Hindernis - umfliege es, du hast kein GPS mehr - erkenne den Rückweg, folge der Person/dem Objekt ... die Liste ist unendlich und unendlich schwierig umzusetzen. Ich denke, es ist Zeit für den fliegenden PC! Hier http://ht4u.net/news/25563_via_praesentiert_49-us-dollar-pc_mit_android/ gibt es z.B eine preiswerte Plattform mit gut Power, die man ohne Problem "leichter löten" könnte. Den Arduino könnten wir weiter verwenden als Schnittstelle (I/O) für Sensoren und PWM.

LG
ROB