MultiWii Release 2.2 ist da!

ronco

Erfahrener Benutzer
Hallo hat niemand die Kombination nanowii mit ppmsum Emfänger der den gleichen Fehler hat
Hi,

in MWC 2.2 haben sie den eigentlich hilfreichen befehl "sei();" in die PPM interrupt routiene gebaut. der macht aber bei manchen PPM emfängern probleme(der atmega32u4 hängt sich auf). um das zu beheben muss man "nur" in der RX.ino datei das besagte sei(); entfernen.


Code:
/**************************************************************************************/
/***************                PPM SUM RX Pin reading             ********************/
/**************************************************************************************/
// attachInterrupt fix for promicro
#if defined(PROMICRO) && defined(SERIAL_SUM_PPM)
  ISR(INT6_vect){rxInt();}
#endif

// PPM_SUM at THROTTLE PIN on MEGA boards
#if defined(PPM_ON_THROTTLE) && defined(MEGA) && defined(SERIAL_SUM_PPM)
  ISR(PCINT2_vect) { if(PINK & (1<<0)) rxInt(); }
#endif

// Read PPM SUM RX Data
#if defined(SERIAL_SUM_PPM)
  void rxInt() {
    uint16_t now,diff;
    static uint16_t last = 0;
    static uint8_t chan = 0;
  #if defined(FAILSAFE)
    static uint8_t GoodPulses;
  #endif
  
    now = micros();
    sei(); <------------------------!!!!!!!!!!!!!! das entfernen!
    diff = now - last;
    last = now;
    if(diff>3000) chan = 0;
    else {
      if(900<diff && diff<2200 && chan<RC_CHANS ) {   //Only if the signal is between these values it is valid, otherwise the failsafe counter should move up
        rcValue[chan] = diff;
        #if defined(FAILSAFE)
          if(chan<4 && diff>FAILSAFE_DETECT_TRESHOLD) GoodPulses |= (1<<chan); // if signal is valid - mark channel as OK
          if(GoodPulses==0x0F) {                                               // If first four chanells have good pulses, clear FailSafe counter
            GoodPulses = 0;
            if(failsafeCnt > 20) failsafeCnt -= 20; else failsafeCnt = 0;
          }
        #endif
      }
    chan++;
  }
}
#endif

nur zur eklärung dieses "sei();" giebt andere interrupts wieder frei .. ist eigentlich gut da das RX lesen so andere MWC aktionen weniger stört. aber es scheint als ob das bei manchen RX zu problemen führt, da so auch der PPM interrupt wieder ausgelösst werden kann. was man alternativ noch versuchen könnte ist, einen 2-4,7kOhm wiederstand an den signal pins des RX und +5V (VCC) zu machen. meine vermutung ist nemmlich das manche PPM RX wohl irgenteinen hohe frequenz zum normalen signal drauf haben .. und diese lösst den interrupt andauernd aus wenn er immer frei ist. mit dem wiederstand würde man das signal halt nochmal in richtung 5V pullen.


gruß

felix
 
hallo leute, ist es möglich nur über den code/ software den onboard gyro gegen einen externen gyro zu tauschen? ich möchte testen ob mein onboard gyro defekt ist weil im flug plötzlich einzelne motoren aussetzen.
 
hallo leute, ist es möglich nur über den code/ software den onboard gyro gegen einen externen gyro zu tauschen? ich möchte testen ob mein onboard gyro defekt ist weil im flug plötzlich einzelne motoren aussetzen.
Hi Joey,

da würde ich vorher (falls nicht schon geschehen) erst mal die Verbindungen zwischen Reglern und Motoren prüfen -> bzw. profilaktisch Nachlöten. Da sind hier schon dutzende Fälle aktenkundig.
Das son Gyro aufgibt ist extrem selten, die Verlötung desselben könnte in seltenen Fällen mal sein.

Tauschen kann man nur, falls es sich um welche handelt, wo an die I²C Adresse einstellen kann, oder verschiedene Typen mit verschiedenen Adressen. Andernfalls kommt nur die "Hammermethode" in Frage, welche bekanntermaßen Endgültig ist.

Gruß Peer
 
hi peer!
wie sich vor wenigen minuten auf dem flugfeld heraus gestellt hat lag das motoren ausfallen an falschen rc mittelwerten:eek:
das ist mir nur durch zufall aufgefallen, dass die min, max und mitten ausser "soll" sind...
nach dem update auf multiwii 2.2 war mir nicht in den sinn gekommen, dass das auch neu kalibriert werden müsste?!
jedenfalls lief das "monstrum" jetzt nach dem korigieren ohne macken:) diese erfahrung hat einiges an kohle gekostet:(
jedenfalls denke ich dass das der fehler war.
ich hätte nicht gedacht dass sich mein 3,6kw quad mit seinen paar kilo so tief ins feld gräbt wenn es nur tief genug fällt:eek:
 
Hallöle,

habe seit etwa einer Woche auch die Version 2.2 am Start.
Alles scheint recht gut zu laufen ...
 
Zuletzt bearbeitet:
Habe nun auch die 2.2 Version auf meinem Crius AIO V2. Auf dem DJI450 Frame komme ich mit den Pitch und Roll Werten von 3.7 ganz gut durch.
Nur mit dem RTH habe ich noch zu kämpfen. Ich weiss auch nicht, aber wenn die RTH aktiviere (mit 8Sat und 1 Fix) geht er zwar in die richtige Richtung aber kurz vor dem Ziel driftet er seitlich weg und geht am Punkt vorbei. Alles zeigt so lamm ohne Bums. Ich frage mich, was habt ihr in der Config geändert? Glaube ja kaum dass es bei allen mit dem Standart-Wert funktioniert?
Ich stelle mir ein anderes Anfliegen vor, er kommt und bremmst mit kurzem Aufschwingen ab, fertig.. und nicht "na ja gehen wir mal in diese Richtung upps war wohl zu weit naja suchen wird den weg langsam wieder zurück".... Wie sieht das bei euch aus? Eingestellt habe ich mit Heck zu mir.
 

ChristophB

Erfahrener Benutzer
Nutzt du das Onboard Magnetometer? Was zeigt der Kompass wenn du die Motoren einschalten?
 
Ja, Kompass bleibt in eine Richtung, egal wie ich Gas gebe. Norden und Süden stimmt. Ich habe MAG auch immer aktiv, wenn da das Problem wäre würde der Copter sich ja auch drehen bei Schub.
Höchstens dass der Wert im Sketch nicht genau stimmt. Mit Luzern (CH) bin ich da bei 1.58. Oder, stimmt schon? Wenn das überhaupt eine Auswirkung hat.
 
... bei einer Genauigkeit des GPS von 5 m oder schlechter,
erwartet Ihr ganz schön viel von den Teilen. Habe mit der aktuellen SW
noch keinen RTH-Test gemacht, erwarte aber eigentlich auch wenig.
 
... bei einer Genauigkeit des GPS von 5 m oder schlechter,
erwartet Ihr ganz schön viel von den Teilen. Habe mit der aktuellen SW
noch keinen RTH-Test gemacht, erwarte aber eigentlich auch wenig.
Also etwas mehr als das wo er jetzt macht erwarte ich schon. Den mit dem MultiWii Pro FC war dies mit der Version 2.1 ziemlich genau.
 

ChristophB

Erfahrener Benutzer
... bei einer Genauigkeit des GPS von 5 m oder schlechter,
erwartet Ihr ganz schön viel von den Teilen. Habe mit der aktuellen SW
noch keinen RTH-Test gemacht, erwarte aber eigentlich auch wenig.
Auch wenn die Ungenauigkeit bei >5m liegt, so ist die Wiederholgenauigkeit schon recht hoch, zumindest in dem kurzen Zeitraum wo wir fliegen, und nur darauf kommt es an. Die absolute Genauigkeit wäre nur bei Wegpunkten von größerer Bedeutung. Wenn ich mich nicht irre, dann habe ich gelesen, daß das Naza auch ein Neo 6 GPS hat.
 

bigbretl

Erfahrener Benutzer
Servus,
für RTH ist es wichtig, dass man vor dem starten der Motoren solange wartet bis er so viele Sat wie möglich hat. Wenn man gleich nach dem SatFix (5) startet kann er die Homeposition auch nicht genau erfassen, dann nützen auch 10 Sat beim zurückfliegen nichts.
Gruß bb
 
Wieso hast du Arm auf einem Schalter? Braucht es doch nicht, wird doch durch Yaw oder Roll aktiviert wie im Sketch erfasst.
 

stars112

Fortgeschritten :-)
Hi,

in MWC 2.2 haben sie den eigentlich hilfreichen befehl "sei();" in die PPM interrupt routiene gebaut. der macht aber bei manchen PPM emfängern probleme(der atmega32u4 hängt sich auf).
Code:
    now = micros();
    sei(); <------------------------!!!!!!!!!!!!!! das entfernen!
    diff = now - last;
Hallo Felix, Danke für diesen Tip!
Das sei() scheint wirklich bei EINIGEN PPM Empfängern echte Probleme zu machen.
Ich hatte so das Problem, daß mit der MW2.2 der 32U4 manchmal einfach nicht richtig booten wollte. Nach dem Anstecken des Akkus blieb der 32u4 einfach stecken. Nach zwei drei mal An/Abstecken des Akkus, hat es dann geklappt. NERVT aber natürlich. Manchmal hing der Proz so ungünstig, daß sogar ein Motor anfing zu laufen:mad:
Ohne den Befehl sei() funktioniert nun alles wunderbar.
Evtl. bei der nächsten Version mal eine "If" mit einbauen, so daß das sei() bei PPM nicht mehr benutzt wird.

Ich habe alles JETI Empfänger hier. klappt aber allen 12 nicht.:rot:

Grüße, Marc
 

ronco

Erfahrener Benutzer
Hi,

ja ich hab an der 2.2 nicht mehr mit gewirkt.. in 2.0 und 2.1 (wo ich den atmega32u4 support eingebaut hatte) war das noch nicht. das hat wer danach rein gebaut. also ich denke ihr wisst das ich eigentlich total pro MWC bin ;) aber ich nehme lieber die 2.1 .. da ich kein gps brauche.. in 2.2 waren sehr viele informatiker aktiv .. und die haben meiner meinung nach sachen eingebaut, nur weils sie es können.. ohne sie wirklich zu testen und ohne wirklichen nutzen für piloten .. aber so ist halt der lauf ...

gruß

Felix
 
Zuletzt bearbeitet:

ernieift

Erfahrener Benutzer
Hallo zusammen,

offenbar ist das SUMH-Protokoll noch nicht in der neuen Multiwii eingebaut. Da ich nicht zu denjenigen gehöre, die die Software pflegen, möchte ich hier auf meine angepasste Version im flyduino-Forum (Bauberichte) hinweisen. Vielleicht macht sich ja jemand die Mühe und baut die Erweiterung in die aktuelle Fassung ein. Ich habe aus Zeitgründen die 2.2er noch nicht getestet. Wenn aber der Spektrum-Code problemlos läuft, dann geht auch SUMH.

Bis dahin
ernieift
 
Zuletzt bearbeitet:

bigbretl

Erfahrener Benutzer
Servus,
habe mal ne Frage zum PH und RTH. Muss ich jetzt nun bei PH und RTH bei den AUX Schaltern auch Mag und Angel zusätzlich einschalten oder wird das automatisch mit erledigt.
Danke
bb
 
FPV1

Banggood

Oben Unten