Funktionieren bei Euch Kompass und Baro vernünftig ?

Roberto

Erfahrener Benutzer
@ weisseruebe:
Was mir aufgefallen ist: Bei Failsave (Wii-Failsave) bleibt der Baromode eingeschaltet. Das hat zur Folge, dass er nicht mehr herunterkommt, wenn FS bei aktivem Baro ausgelöst wird.
Herzlichen Dank für Deine Info!!
Daran hatte ich nicht gedacht, als ich den "sicheren Ausgang" aus Barologic2 programmierte. Dabei müsste es auftreten:
Code:
#define Barologic2  
//#define Rapid_Exit_Barologic2
Wenn im Flug in diesem Baromodus eine Failsavesituation auftritt, dann wird ewig im Baromodus2 gewartet, bis der Throttlestick das virtuelle Gas erreicht.
Das Problem müsste durch #define Rapid_Exit_Barologic2 für das erste zu lösen sein. Ich mache aber noch eine FS-Abfrage rein.

@helste:
Sehr schön!!

Ich hoffe, ich komme heute am Abend dazu.
Die Wetten stehen 100:1 - das wird heute Abend noch fertig :)

LG
Rob
 

weisseruebe

Erfahrener Benutzer
Bei mir ist es allerdings in Barologic1...

Ich habe gerade mal in den Code geschaut. Das ist bisher offenbar einfach nicht anders vorgesehen. Es wird ACC hinzugeschaltet bei Failsave, aber mehr passiert nicht.

if (( rcOptions[BOXACC] || (failsafeCnt > 5*FAILSAVE_DELAY) ) && ACC ) {
// bumpless transfer to Level mode
if (!f.ACC_MODE) {
errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
f.ACC_MODE = 1;
}
} else {
// failsafe support
f.ACC_MODE = 0;
}

Ein simples f.BARO_MODE = 0; müsste ja reichen, um den Baro-Mode abzuschalten. Genialer wäre natürlich ein langsames sinken mit Baromode, oder RTH ;-)
Ich werde es mal testen, wenn ich mit dem Laptop im Park bin.
 

helste

Erfahrener Benutzer
Die Wetten stehen 100:1 - das wird heute Abend noch fertig :)

LG
Rob
Rob, ich fürchte, das wird sich nicht ausgehen. Habe heute nicht nur das AIO bekommen, sondern auch die Horyzon HD V2 und den DV02 Portable DVR. Das muss natürlich auch mal inspiziert werden.
Vorallem bin ich mir noch nicht sicher, auf welchen Kopter ich die AIO bauen will. Zur Auswahl steht der Y3, den ich aus dem großen Y6 mache oder der H-Quad, den ich aus dem X-Quad umbaue. Oder ich lasse mal den X-Quad und mach das Board gleich rauf, um schneller zum Testen zu kommen.
Da bin ich noch unschlüssig. Ist ja auch noch ein APM2.5 Clone zu mir unterwegs und das kommt dann halt auf den jeweils anderen Kopter. Den FPV Raptor hätte ich aber auch zu bestücken. Da kommt entwedser das APM1 drauf, oder der APM2.5 Clone.
Gar nicht so einfach da eine Wahl zu treffen.
Was das AIO betrifft, so gibt es da ja auch die Möglichkeit die MP Sogftware drauf zu tun. Mache ich aber nicht. Da bleibe ich doch Deiner Multiwii Version treu. Vielleicht probier ich die MP mal aus, aber da die der Ardupilot eh ähnlich sein dürfte, und ich dann eh 3 Stück APMs habe, ist das nicht wirklich interessant.

Wollte eigentlich heute gar nicht mehr das AIO in die Hand nehmen und mich im die Horyzon und den Recorder kümmern, aber jetzt hast mich irgendwie motiviert.
Werde mal den Lötkolben anwerfen und den X-Quad mit dem AIO an den Start bringen;-)

Jetzt muss ich nur noch schauen, wie ich die vielen beiligenden Kabel samt Stecker am besten nutze um das GPS anzuschließen.

Mal schauen, ob es heute noch Maiden gibt.
 

helste

Erfahrener Benutzer
Die Firmware ist drauf. Upload blieb zuerst schon beim EEPromlöschen hängen. Ich musste einmal reset drücken, dann ging es beim nächsten mal. FW ging dann sofort drauf.
Jetzt mach ich mal das GPS dran und kleb den Baro ab.
 

helste

Erfahrener Benutzer
Das Board nervt mich jetzt schon. Habe zwar schon den ersten Flug hinter mir (eher Kampfschweben), aber das Verbinden zum Board geht mal und mal nicht. Will gerade die PID Werte verstellen, aber jetzt verbindet es sich schon wieder nicht.
Clicke in der GUI auf Com11 und dann auf Start. Flatline, und keine Werte werden eingelesen. Hatte ich vorhin auch ständig, ging dann aber nach Abstecken und GUI neu starten hin und wieder.
Jetzt geht mal gar nichts.
Gibt's da ein bekanntes Problem,welches ich im AIO Thread überlesen habe?
 

Roberto

Erfahrener Benutzer
@ weisseruebe:

Ich habe gerade mal in den Code geschaut. Das ist bisher offenbar einfach nicht anders vorgesehen. Es wird ACC hinzugeschaltet bei Failsave, aber mehr passiert nicht.
EDIT: Ich beziehe mich hier auf die "MultiWii_2_1_NewBaroPIDVario4Final".
Mehr muss auch eigentlich nicht passieren. Es dürfte eigentlich nur in Barologic2 ohne rapid exit ein Problem geben können.
Es wird abgefragt, ob der Baroschalter umgelegt ist (rcOptions[BOXBARO]). Wenn im FS und Barologic1 das Althold noch aktiv ist, dann muss bei Dir der Empfänger noch ein "Baroschalter EIN" senden. Vielleicht ist auch Dein FAILSAVE_THROTTLE zu hoch, und es sieht nur wie ein Althold aus? Das f.BARO_MODE wird nur verwendet um zu signalisieren, dass nach umlegen des Baroschalters die Barovariablen initialisiert wurden. Dadurch wird verhindert, dass bei jedem Durchlauf im Zustand "Baroschalter EIN" die Barovariablen neu initialisiert werden.

Für mein oben beschriebenes Problem (Failsave & Barologic2 ohne rapid exit) würde ich folgendes vorschlagen:
Code:
    // Failsafe routine - added by MIS
    #if defined(FAILSAFE)
      if ( failsafeCnt > (5*FAILSAVE_DELAY) && f.ARMED) {                  // Stabilize, and set Throttle to specified level
        for(i=0; i<3; i++) rcData[i] = MIDRC;                               // after specified guard time after RC signal is lost (in 0.1sec)
        #if defined(Barologic2) && !defined(Rapid_Exit_Barologic2)
          BaroExit = 0;
        #endif
        rcData[THROTTLE] = FAILSAVE_THROTTLE;
        if (failsafeCnt > 5*(FAILSAVE_DELAY+FAILSAVE_OFF_DELAY)) {          // Turn OFF motors after specified Time (in 0.1sec)
          f.ARMED = 0;   // This will prevent the copter to automatically rearm if failsafe shuts it down and prevents
          f.OK_TO_ARM = 0; // to restart accidentely by just reconnect to the tx - you will have to switch off first to rearm
        }
        failsafeEvents++;
      }
      if ( failsafeCnt > (5*FAILSAVE_DELAY) && !f.ARMED) {  //Turn of "Ok To arm to prevent the motors from spinning after repowering the RX with low throttle and aux to arm
          f.ARMED = 0;   // This will prevent the copter to automatically rearm if failsafe shuts it down and prevents
          f.OK_TO_ARM = 0; // to restart accidentely by just reconnect to the tx - you will have to switch off first to rearm
      }
      failsafeCnt++;
    #endif
    // end of failsave routine - next change is made with RcOptions setting
Für Failsave & Barologic1 sehe ich bei Durchsicht des Codes eigentlich kein Problem. Da muss ich demnächst mal einen Praxistest machen. Schau bitte auch nochmal nach.

@helste: Danke, dass Du der Multiwii treu bleibst! Bei 3 APMs im Haus wird es ja sonst auch zu langweilig...
Wenn Du mal auf Sebbi's Wunschzettel schaust: https://trello.com/board/multiwii-development-unofficial/507da48409680c4c4d688e4c siehst Du unter "Known issues", dass es mit dem aktuellen Mwii Code wohl zu Problemen mit dem Tricopter Heckservo kommen kann. Vielleicht baust Du besser keinen Tri mit der 2.1 FW.

... aber jetzt hast mich irgendwie motiviert....
Jetzt bin ich Schuld! - Damit kann ich gut leben :) .


EDIT:
Gibt's da ein bekanntes Problem,welches ich im AIO Thread überlesen habe?
Vielleicht hat das etwas mit diesem schwachmatischen USB Anschluss zu tun?

LG
Rob
 

FireN

trägt sonst keine Brille!
ich hatte das problem bei der multiwii auch,bzw ab und zu ist es noch so, das liegt eher an der software auf dem pc.
ich nehme an du hast die java variante? dann guck mal beim task manager nach der "jawaw".exe oder so ähnlich, wenn die offen ist aber multiwiigui zu dann beende mal alle jawaw.exe

Beim starten kann man generell sagen: erst copter ans usb und dann erst das programm starten.

mfg
 

helste

Erfahrener Benutzer
So, geht doch. Das USB Port ist sehr heikel. Man muss da wirklich sehr genau sein, beim Anstecken des Kabels.
Naja, geht nun. War aber nur ein ganz kurzer Flug. Der Kopter eiert ganz übel herum. Kaum zu fliegen. Hat er unmittelbar vorher mit dem AQ50 nicht gemacht. Muss da morgen noch mal in Ruhe drüber schauen.
Ich weiß auch nicht, ob sich das jetzt mit dem X-Quad noch lohnt. Eventuell bastle ich da gleich den H-Quad. Mal eine Nacht drüber schlafen. Rom ist schließlich auch nicht an einem Tag erbaut worden.
 

helste

Erfahrener Benutzer
Ich habe auch schon kurz wegen FTDI überlegt, aber die Lötstation war schon ausgeschaltet und da wollte ich dann nicht mehr. Jetzt hat es aber dann eh wieder funktioniert. Mal sehen, wie das weiter geht.
Javaw.exe war offenbar nicht das Problem.

So, habe es noch mal versucht. Wieder das gleiche Problem.
Wenn ich in der GUI auf start drücke, dann blinkt das blaue LED neben dem USB wie verrückt. Das ist RX. Das rote LED für TX ist dunkel. Das flackert nur beim Anstecken kurz auf.
Da liegt irgendwo der Hund begraben. Werde mir morgen einen FTDI Kabel dafür löten. Vielleicht geht es damit besser.
 

helste

Erfahrener Benutzer
Jetzt geht es wieder. Wenn es einmal geht, dann kann man trenne, verbinden, GUI zu machen, aufmachen, dann geht es immer.
Mir ist aufgefallen, dass es hauptsächlich geht, wenn ich das USBkabel zuerst am Board und erst dann am PC anstecke.

Wird jetzt aber wohl sehr OT hier.
 

Roberto

Erfahrener Benutzer
@helste: Schon #define MPU6050_LPF_42HZ reingedreht?

"Wird jetzt aber wohl sehr OT hier. " - jeder darf mal... Aber ist irgendwie nicht weit weg vom Thema. Solange noch keine Kochrezepte ausgetauscht werden...

LG
Rob
 

helste

Erfahrener Benutzer
Ja, das mache ich immer schon standardmäßig. Ich weiß auch wie genau der Kopter fliegt, wenn ich das nicht mache. Das ist definitiv anders und bei weitem nicht so schlimm.
Ich habe jetzt mal die PID Werte eingestellt, die ich mir für den Kopter abgespeichert hatte, als da noch das Crius SE drauf war. Die haben da super funktioniert.
Nutzt nichts. Das Teil eiert herum und schaukelt sich auf. Wenn ich da nicht ganz vorsichtig mit dem rechten Stick bin, schaukelt er sich bis zum Salto auf.
Vermutlich habe ich irgendwas noch übersehen, aber um die Zeit finde ich das nicht mehr. Fällt mir vielleicht wieder im Bett ein, oder morgen, wenn ich kurz mal drüber schaue.
 

weisseruebe

Erfahrener Benutzer
Zum Failsave: Ich habe es nur ein Mal probiert. Aber da war ich 99% sicher, dass Alt noch an war. Er hielt sich sehr brav auf Höhe und ich konnte ihn per Hand runterdrücken, er kam wieder hoch und blieb dann dort.

Ich schaue mal in der Gui, was vom Empfänger kommt, wenn der Sender aus ist.
 

Roberto

Erfahrener Benutzer
@ weisseruebe: Trotzdem Danke, dass Du mich zum Nachdenken gebracht hast, das FS ist meine nächste Baustelle. Aktuell wäre ein FS mit Hüpfen auf dem Boden (wie beim Naza) denkbar, da der Kopter mit Sicherheit feststellen muss, ob er gelandet ist. Nicht das Luftdruckschwankungen (Bodenhöhe kann nicht mehr richtig erkannt werden) und ACC - Gewitter (Turbulenzen) ihn schon in der Luft zu der Annahme verleiten. Kostenaufwändige, schwere und zusätzlich stromfressende Sensoren (Sonar/Radar/IR-Sensor) wären natürlich eine Lösung. Vielleicht würden es auch 1 bis 2 simple Tast-Schalter in den Landebeinen machen. D.h. "Ich habe mit 100%tiger Sicherheit Boden unter den Füssen - ich bin gelandet und schalte jetzt alles aus" Dafür könnte man auch z.B den "Batteriepin" nehmen. Nur eine Idee. Ich bin für alle Lösungsvorschläge offen. (Nach dieser Steilvorlage muss eigentlich kommen: "Offen für alles und nicht ganz dicht")
Da fällt mir noch eine Möglichkeit ein: "Ich liege auf dem Rücken und meine Höhe ändert sich nicht um 1,5 meter (BMP085 Messungenauigkeit mit dabei) nach unten innerhalb von 3 Sek" - Schalte alles ab.

LG
Rob
 

weisseruebe

Erfahrener Benutzer
So, ich habe mal getestet. Wenn man meine Th9X 2,4Ghz abschaltet, bleiben die Kanäle einfach, wie sie sind.
Also bleibt auch Baro angeschaltet. Da die Th9X wohl kein RX-Failsafe bei 2,4Ghz hat, sollte ich mal probieren, das Baro aktiv abzuschalten. Woran wird dann eigentlich überhaupt Failsafe von der Software erkannt?

Die Idee mit dem Taster ist ziemlich gut. Geht halt nur, wenn man wirklich am Boden ankommt, aber besser, als nichts ;-)
 

upapa

Erfahrener Benutzer
So, geht doch. Das USB Port ist sehr heikel. Man muss da wirklich sehr genau sein, beim Anstecken des Kabels.
Hi helste,
habe bei meinem AIO die USB-Buchse mit Sekundenkleber stabilisiert. Dann kann man ohne Schweißperlen auf der Stirn mit dem USB-Kabel hantieren. :)

Naja, geht nun. War aber nur ein ganz kurzer Flug. Der Kopter eiert ganz übel herum. Kaum zu fliegen. Hat er unmittelbar vorher mit dem AQ50 nicht gemacht. Muss da morgen noch mal in Ruhe drüber schauen.
Kann ich von meinem AIO nicht sagen, im Gegenteil: War von Anfang an (und bin es immer noch) begeistert vom Flugverhalten.

upapa
 

Roberto

Erfahrener Benutzer
@Weissruebe:
"Also bleibt auch Baro angeschaltet"
Ich habs doch geahnt! Soweit ich die original Turnigy Anleitung verstehe, kannst Du Dort auch ein Failsave programmieren.

"Woran wird dann eigentlich überhaupt Failsafe von der Software erkannt?"
Im Abschnitt RX.ino wird geschaut, ob der Throttlekanal lange genug "tot" ist (also nicht "0" Gas, das wäre immerhin ein Wert von 950-1000) dann wird ein FS ausgelöst. Im Falle des Summensignals wird dessen Ausbleiben registriert.

Tja, der Schalter ist auch noch nicht der Weisheit letzter Schluss. Aktuell habe ich mir 3 Failsave Szenarien überlegt.
Je nach dem, was für Sensoren dabei sind:
Alles im "Level" Modus:
Failsave 1 (GYRO/ACC/BARO): Warte Zeit X, Autolandung
Failsave 2 (GYRO/ACC/BARO/MAG): Steige auf eine Höhe X m, warte X sec, fliege für Zeit X sec auf den Piloten zu (einfach Kippwinkel 5-10 Grad oder so) warte Zeit X, dann Autolandung. Bedingung: Zeit X ist kleiner Flugzeit, sonst zeit X = Flugzeit
Failsave 3 (GYRO/ACC/BARO/GPS): Steige auf eine Höhe X m, warte X sec, RTL, warte, dann Autolandung

Zuerst muss natürlich die Autolandung programmiert werden.
Vielleicht so:
Autolandung: Baro ein, Sinkrate ca 0,5m/s. wenn über 5 Sek die tiefste höhe nicht um 1m unterschritten wurde und in der Zeit das Gas schon ein mal Standgas+10% unterschritten hatte, dann gehe von einer Landung aus.

@Upapa: Moin! Das wäre ja ganz was neues, wenn Helste den Gaul nicht zugeritten bekommt.

LG
Rob
 

upapa

Erfahrener Benutzer
Kostenaufwändige, schwere und zusätzlich stromfressende Sensoren (Sonar/Radar/IR-Sensor) wären natürlich eine Lösung.
Hi Roberto,
so schwer ist ein Sonar-Modul ja nun auch wieder nicht. :)
Habe am Rabbit ein HC-SR04 im Einsatz (bringt 8 Gramm auf die Waage). Funktioniert auch sehr gut bei relativ glattem Untergrund (Beton, Sand, Ackerkrume o.ä.). Aber sobald Gras ins Spiel kommt, sieht es nicht mehr so toll aus. Wenn man in diesem Fall die aus dem Ultraschall-Echo auftretenden "Irritationen" regeltechnisch kompensieren könnte, wäre Sonar bestimmt eine elegante Lösung...

upapa
 

upapa

Erfahrener Benutzer
Zuerst muss natürlich die Autolandung programmiert werden.
Vielleicht so:
Autolandung: Baro ein, Sinkrate ca 0,5m/s. wenn über 5 Sek die tiefste höhe nicht um 1m unterschritten wurde und in der Zeit das Gas schon ein mal Standgas+10% unterschritten hatte, dann gehe von einer Landung aus.
Moin Roberto,
unter http://www.multiwii.com/forum/viewtopic.php?f=7&t=2643 hat MIS eine MultiWii-Version mit einer Reihe interessanter Funktionen, u.a. "- failsafe with RTH at specified altitude and AutoLanding", zusammengestellt. Vielleicht ein Inspirations-Geber? :)

upapa
 
FPV1

Banggood

Oben Unten