Versuch Crius AIO mit Multiwii zu testen - kein upload möglich!

manfred59 · Jan 18, 2014

Hi!
Nachdem ich mich mehrere Wochen mit Megapirat Software herumgeschlagen habe, wollte ich mich nach äußerst frustrierenden Flugversuchen der Multiwii Soft zuwenden. Das Problem mit der Megapirate 3.01 war wohl der interne Kompass, mitten im Flug hat sich die Rollfunktion einfach umgedreht, Absturz aus geringer Höhe endete glimpflich. Hab zwar den compassmot durchgeführt x-mal kalibriert, hat nichts genützt. Jetzt wollte ich mal die MultiWii v2.3 versuchen, aber ich schaff es nicht sie über USB hochzuladen. Hab alle Einstellungen nach Angabe aus Anleitungen von Gaza07aus dem engl. Board (http://www.multi-rotor.co.uk/index.php?topic=1762.0) gemacht, wie #define QUADX etc. dann die Überprüfung und als Ergebnis eine Latte mit Fehlermeldungen... :???:

Kann es vielleicht auch an 3DR Radio liegen, das hab ich auch noch am Serial port 1~3 hängen?
Oder ist es entscheidend welche Arduino soft man nehmen muss? Hab die arduino v1.05 verwendet.
Weiß momentan nicht was ich noch versuchen könnte.
Manfred

-Ralf- · Jan 18, 2014

Manfred,

schick doch mal einen Screenshot deiner Fehlermeldungen,
und deine (gezippte) config.h .....

3DR-Radio schließe ich aus ..... das FTDI nutzt Serial 0.
Du mußt natürlich den virtuellen Com-Port nutzen, der dem
FTDI zugeordnet ist.

manfred59 · Jan 18, 2014

Ich habe nur den Coptertyp geändert, ansonsten alles gelassen, trotzdem so viele Fehlermeldungen!!

Building for MegaPirateNG
Excluding arduino core from include paths
Alarms.cpp:1:21: error: Arduino.h: No such file or directory
In file included from Alarms.cpp:4:
types.h:86: error: 'int16_t' does not name a type
types.h:87: error: 'int16_t' does not name a type
types.h:88: error: 'int16_t' does not name a type
types.h:89: error: 'int16_t' does not name a type
types.h:90: error: 'int16_t' does not name a type
types.h:94: error: 'uint8_t' does not name a type
types.h:95: error: 'uint16_t' does not name a type
types.h:96: error: 'uint16_t' does not name a type
types.h:97: error: 'uint16_t' does not name a type
types.h:101: error: 'int32_t' does not name a type
types.h:102: error: 'int16_t' does not name a type
types.h:106: error: 'int16_t' does not name a type
types.h:107: error: 'int16_t' does not name a type
types.h:111: error: 'uint8_t' does not name a type
types.h:112: error: 'uint8_t' does not name a type
types.h:113: error: 'uint8_t' does not name a type
types.h:114: error: 'uint8_t' does not name a type
types.h:115: error: 'uint8_t' does not name a type
types.h:116: error: 'uint8_t' does not name a type
types.h:117: error: 'uint8_t' does not name a type
types.h:118: error: 'uint8_t' does not name a type
types.h:119: error: 'uint8_t' does not name a type
types.h:120: error: 'uint8_t' does not name a type
types.h:121: error: 'uint8_t' does not name a type
types.h:122: error: 'uint8_t' does not name a type
types.h:123: error: 'uint8_t' does not name a type
types.h:124: error: 'uint8_t' does not name a type
types.h:125: error: 'uint8_t' does not name a type
types.h:126: error: 'uint8_t' does not name a type
types.h:127: error: 'uint8_t' does not name a type
types.h:128: error: 'uint8_t' does not name a type
types.h:132: error: 'uint8_t' does not name a type
types.h:133: error: 'int16_t' does not name a type
types.h:134: error: 'int16_t' does not name a type
types.h:135: error: 'uint16_t' does not name a type
types.h:136: error: 'uint8_t' does not name a type
types.h:140: error: 'uint8_t' does not name a type
types.h:141: error: 'uint8_t' does not name a type
types.h:142: error: 'uint8_t' does not name a type
types.h:146: error: 'int16_t' does not name a type
types.h:147: error: 'int16_t' does not name a type
types.h:148: error: 'int16_t' does not name a type
types.h:149: error: 'int8_t' does not name a type
types.h:154: error: 'uint8_t' does not name a type
types.h:155: error: 'uint8_t' does not name a type
types.h:156: error: 'uint8_t' does not name a type
types.h:157: error: 'uint8_t' does not name a type
types.h:158: error: 'uint8_t' does not name a type
types.h:159: error: 'uint8_t' does not name a type
types.h:160: error: 'uint8_t' does not name a type
types.h:161: error: 'int16_t' does not name a type
types.h:162: error: 'uint16_t' does not name a type
types.h:163: error: 'uint8_t' does not name a type
types.h:192: error: 'int16_t' does not name a type
types.h:197: error: 'uint8_t' does not name a type
In file included from Alarms.cpp:5:
MultiWii.h:31: error: 'uint8_t' does not name a type
MultiWii.h:33: error: 'uint32_t' does not name a type
MultiWii.h:34: error: 'uint16_t' does not name a type
MultiWii.h:35: error: 'uint16_t' does not name a type
MultiWii.h:36: error: 'uint16_t' does not name a type
MultiWii.h:37: error: 'uint16_t' does not name a type
MultiWii.h:38: error: 'uint16_t' does not name a type
MultiWii.h:39: error: 'int16_t' does not name a type
MultiWii.h:40: error: 'uint8_t' does not name a type
MultiWii.h:41: error: 'uint8_t' does not name a type
MultiWii.h:42: error: 'int32_t' does not name a type
MultiWii.h:43: error: 'int16_t' does not name a type
MultiWii.h:44: error: 'int16_t' does not name a type
MultiWii.h:45: error: 'int16_t' does not name a type
MultiWii.h:47: error: 'int16_t' does not name a type
MultiWii.h:48: error: 'uint8_t' does not name a type
MultiWii.h:59: error: 'int16_t' does not name a type
MultiWii.h:63: error: 'int16_t' does not name a type
MultiWii.h:65: error: 'uint16_t' does not name a type
MultiWii.h:67: error: 'int16_t' does not name a type
MultiWii.h:68: error: 'int16_t' does not name a type
MultiWii.h:77: error: 'int16_t' does not name a type
MultiWii.h:78: error: 'int16_t' does not name a type
MultiWii.h:79: error: 'int16_t' does not name a type
MultiWii.h:81: error: 'int16_t' does not name a type
MultiWii.h:82: error: 'int16_t' does not name a type
MultiWii.h:84: error: 'int16_t' does not name a type
MultiWii.h:85: error: 'int16_t' does not name a type
MultiWii.h:86: error: 'int16_t' does not name a type
MultiWii.h:87: error: 'uint8_t' does not name a type
MultiWii.h:88: error: 'int16_t' does not name a type
MultiWii.h:89: error: 'int16_t' does not name a type
MultiWii.h:123: error: 'int16_t' does not name a type
MultiWii.h:124: error: 'int32_t' does not name a type
MultiWii.h:125: error: 'int32_t' does not name a type
MultiWii.h:126: error: 'int32_t' does not name a type
MultiWii.h:127: error: 'uint8_t' does not name a type
MultiWii.h:128: error: 'uint16_t' does not name a type
MultiWii.h:129: error: 'int16_t' does not name a type
MultiWii.h:130: error: 'uint16_t' does not name a type
MultiWii.h:131: error: 'uint16_t' does not name a type
MultiWii.h:132: error: 'uint8_t' does not name a type
MultiWii.h:133: error: 'uint16_t' does not name a type
MultiWii.h:134: error: 'uint8_t' does not name a type
MultiWii.h:135: error: 'uint8_t' does not name a type
MultiWii.h:146: error: 'uint8_t' does not name a type
MultiWii.h:147: error: 'int16_t' does not name a type
MultiWii.h:148: error: 'int16_t' does not name a type
MultiWii.h:173: error: 'uint8_t' does not name a type
MultiWii.h:174: error: 'uint32_t' does not name a type
In file included from Alarms.cpp:6:
LCD.h:5: error: variable or field 'LCDprint' declared void
LCD.h:5: error: 'uint8_t' was not declared in this scope
LCD.h:11: error: variable or field 'toggle_telemetry' declared void
LCD.h:11: error: 'uint8_t' was not declared in this scope
LCD.h:12: error: variable or field 'dumpPLog' declared void
LCD.h:12: error: 'uint8_t' was not declared in this scope
In file included from Alarms.cpp:7:
Sensors.h:29: error: variable or field 'i2c_rep_start' declared void
Sensors.h:29: error: 'uint8_t' was not declared in this scope
Sensors.h:30: error: variable or field 'i2c_write' declared void
Sensors.h:30: error: 'uint8_t' was not declared in this scope
Sensors.h:32: error: variable or field 'i2c_write' declared void
Sensors.h:32: error: 'uint8_t' was not declared in this scope
Sensors.h:33: error: variable or field 'i2c_writeReg' declared void
Sensors.h:33: error: 'uint8_t' was not declared in this scope
Sensors.h:33: error: 'uint8_t' was not declared in this scope
Sensors.h:33: error: 'uint8_t' was not declared in this scope
Sensors.h:34: error: 'uint8_t' does not name a type
Sensors.h:35: error: 'uint8_t' does not name a type
Sensors.h:36: error: 'uint8_t' does not name a type
In file included from Alarms.cpp:8:
Alarms.h:4: error: variable or field 'blinkLED' declared void
Alarms.h:4: error: 'uint8_t' was not declared in this scope
Alarms.h:4: error: 'uint8_t' was not declared in this scope
Alarms.h:4: error: 'uint8_t' was not declared in this scope
Alarms.h:5: error: 'uint8_t' does not name a type
Alarms.h:12: error: variable or field 'led_flasher_set_sequence' declared void
Alarms.h:12: error: 'uint8_t' was not declared in this scope
Alarms.h:16: error: variable or field 'PilotLamp' declared void
Alarms.h:16: error: 'uint8_t' was not declared in this scope
Alarms.cpp:11: error: variable or field 'patternDecode' declared void
Alarms.cpp:11: error: 'uint8_t' was not declared in this scope
Alarms.cpp:11: error: 'uint16_t' was not declared in this scope
Alarms.cpp:11: error: 'uint16_t' was not declared in this scope
Alarms.cpp:11: error: 'uint16_t' was not declared in this scope
Alarms.cpp:11: error: 'uint16_t' was not declared in this scope
Alarms.cpp:11: error: 'uint16_t' was not declared in this scope
Alarms.cpp:12: error: variable or field 'setTiming' declared void
Alarms.cpp:12: error: 'uint8_t' was not declared in this scope
Alarms.cpp:12: error: 'uint16_t' was not declared in this scope
Alarms.cpp:12: error: 'uint16_t' was not declared in this scope
Alarms.cpp:13: error: variable or field 'turnOff' declared void
Alarms.cpp:13: error: 'uint8_t' was not declared in this scope
Alarms.cpp:14: error: variable or field 'toggleResource' declared void
Alarms.cpp:14: error: 'uint8_t' was not declared in this scope
Alarms.cpp:14: error: 'uint8_t' was not declared in this scope
Alarms.cpp:15: error: variable or field 'vario_output' declared void
Alarms.cpp:15: error: 'uint16_t' was not declared in this scope
Alarms.cpp:15: error: 'uint8_t' was not declared in this scope
Alarms.cpp:16: error: variable or field 'switch_led_flasher' declared void
Alarms.cpp:16: error: 'uint8_t' was not declared in this scope
Alarms.cpp:17: error: variable or field 'switch_landing_lights' declared void
Alarms.cpp:17: error: 'uint8_t' was not declared in this scope
Alarms.cpp:18: error: variable or field 'PilotLampSequence' declared void
Alarms.cpp:18: error: 'uint16_t' was not declared in this scope
Alarms.cpp:18: error: 'uint16_t' was not declared in this scope
Alarms.cpp:18: error: 'uint8_t' was not declared in this scope
Alarms.cpp:20: error: 'uint8_t' does not name a type
Alarms.cpp:20: error: expected unqualified-id before ',' token
Alarms.cpp:21: error: expected constructor, destructor, or type conversion before '=' token
Alarms.cpp:22: error: 'uint32_t' does not name a type
Alarms.cpp:23: error: 'int16_t' does not name a type
Alarms.cpp:25: error: 'uint8_t' does not name a type
Alarms.cpp:30: error: 'uint8_t' does not name a type
Alarms.cpp: In function 'void alarmHandler()':
Alarms.cpp:111: error: 'i2c_errors_count' was not declared in this scope
Alarms.cpp:111: error: 'i2c_errors_count_old' was not declared in this scope
Alarms.cpp:111: error: 'alarmArray' was not declared in this scope
Alarms.cpp:112: error: 'alarmArray' was not declared in this scope
Alarms.cpp: At global scope:
Alarms.cpp:167: error: variable or field 'patternDecode' declared void
Alarms.cpp:167: error: 'uint8_t' was not declared in this scope
Alarms.cpp:167: error: 'uint16_t' was not declared in this scope
Alarms.cpp:167: error: 'uint16_t' was not declared in this scope
Alarms.cpp:167: error: 'uint16_t' was not declared in this scope
Alarms.cpp:167: error: 'uint16_t' was not declared in this scope
Alarms.cpp:167: error: 'uint16_t' was not declared in this scope

Es handelt sich um die v 2.3 von MultiWii. Hier noch die config.h Anhang anzeigen config.h.txt.zip
Manfred

-Ralf- · Jan 18, 2014

Also, das ist die types.h, nicht die config.h ......

und wieso macht du ein Build für MegaPirateNG ???

Deine Multiwii 2.3 - Dateien müssen in einem Ordner "Multiwii" liegen, da öffnest du
dann die MultiWii.ino in Arduino .....

-Ralf- · Jan 18, 2014

.... und natürlich mußt du in der config.h dein Board auswählen

manfred59 · Jan 18, 2014

@ Ralf
sorry, hab die falsche conf erwischt, aber dein Tipp mit dem Board Namen war der springende Punkt.
Habs jetzt hochgeladen acc u. mag. kalibriert, jedoch bin ich etwas ratlos, da die MultiWiConf nur jedes zweite Mal verbinden richtig funktioniert. Wie kann ich bei MultiWii die Escs kalibrieren, bei Megapirates Soft gings ja ganz einfach.
Lt. dieser Anleitung gehts bei mir noch nicht:
1.Disconnect USB
2.Put the throttle high and connect the Lipo to power the APM
3.When the APM boots the lights will cycle continuously
4.Disconnect the Lipo and reconnect it. High PWM will be sent to the ESCs triggering calibration
5.Drop your throttle stick to the lowest position. You should hear a confirmation/arming beep or two.
Move the throttle to confirm all ESCs are armed and the motors are working in sync.
Muss ich da in der config.h noch etwas aktivieren?
Grüsse, Manfred

-Ralf- · Jan 18, 2014

Du mußt in der config.h

ESC_CALIB_CANNOT_FLY

aktivieren, flashen, laufen lassen.
Danach wieder auskommentieren und neu flashen.

Und das ganze ohne Props!

Goetz_Cologne · Jan 19, 2014

manfred59 hat gesagt.:

Hallo Manfred,
nicht böse gemeint, aber ich habe den Eindruck Du musst Dich unbedingt präziser mit der Sache auseinandersetzen, wenn das etwas werden soll. Die falsche Datei geöffnet, die falsche Datei ins Forum geladen, bei Verbindungsproblemen zwischen dem AIO-Board und der MW-Gui mal eben die ESC's kalibrieren, dann eine Anleitung für APM versuchen obwohl Du gerade MW geflashed hast....... puuh.....
Tu Dir selbst den Gefallen und lass Dir etwas mehr Zeit für Konzentration und Sorgfalt, sonst wird es nur sehr frustrierend und ärgerlich.
Wie gesagt - nicht böse gemeint, ich spreche aus eigener Erfahrung ;-)
Viel Erfolg wünsche ich Dir.

P.S.: Die ESC müssen meines Erachtens nicht neu kalibriert werden; die Signalwege sind doch gleich?

-Ralf- · Jan 19, 2014

Die Signalwege werden von der FC vorgegeben, sie liegen zwischen MINCOMMAND und MAXTHROTTLE.
Das kann von der Fernsteuerung abweichen.

manfred59 · Jan 19, 2014

@Goetz_Cologne
Na ja du hast schon recht, mit MultiWii beschäftige ich mich erst seit zwei Tagen, aber die Wochen davor hatte ich mich schon sehr eingehend mit CriusAIO v.2 (MegaPirate Soft) beschäftigt, obwohl ich nicht wirklich zu einem Ergebnis gekommen bin mit dem ich zufrieden gewesen wäre. Meine bisherigen Erfahrungen mit Coptern: Tricopter mit KK Board, ist sicherlich wesentlich einfacher in der Handhabung - er war relativ einfach zu bauen und fliegen. Der nächste Schritt sollte ein Copter mit GPS Funktionen Alt-hold, Loiter, RTL etc. sein. Dazu fräste ich mir den frame des QX9 Copters aus CFK und besorgte das APM2.5 und verschiedene andere Komponenten. Leider ging das AMP durch eine zu hohe Spannung >5,2 V kaputt (wird gerade von rctimer ausgetauscht)

Ersatz sollte das CriusAIO v.2 Board sein, das ich mir kurzerhand bestellte. Bis alles soweit konfiguriert und verbunden war habe ich sicherlich einige hundert Seiten u. Videos studiert. Es hat eigentlich soweit ales funktioniert bis auf das Problem mit dem Kompass vor zwei Tagen, wo der Roll plötzlich im Schwebeflug in 2m Höhe verkehrt herum reagierte, ein Absturz war nicht zu verhindern, aber es blieb alles Gott sei dank heil.
Das war der Grund es einmal mit MultiWii zu versuchen.

Leider nein im WIconf sehe ich die 4 Motore mit unterschiedlichen Werten re hinten u. li vo drehen langsamer bzw. beginnen später zu drehen.
Hab heute einen Testschwebeflug probiert -trotz dieser Unregelmäßigkeiten - er fliegt relativ ohne größere Probleme.
In einem Video hab ich noch erfahren wie man die unregelmäßig laufenden Motore mittels Stickeingabe anpasst, das hab ich unter MegaPirate Software nicht machen müssen, da haben alle Motore nach der Kalibrierung gleich gearbeitet!
Ich würde mich sehr freuen, wenn mir jemand ein paar grundlegende links zum Thema MultiWii 2.3 liefern könnte, das würde es mir dann natürlich immens erleichtern. Die meisten die man im Netz findet beziehen sich auf ältere Versionen.
Schon jetzt einen herzlichen Dank von einem Modellflugpiloten mit 37 jähriger Modellflugpraxis, davon 20 Jahre im Elektro-Wettbewerbsgeschehen (Klasse F5B).
Manfred

-Ralf- · Jan 19, 2014

Das die Motoren unterschiedlich laufen, solange du am Boden bist, ist normal.
Das liegt an den I-Anteilen der PID`s. Da muss man gar nichts anpassen, einfach nur
zügig starten.

Goetz_Cologne · Jan 19, 2014

Das die Steuerwege von der (egal welche) FC vorgegeben werden ist klar, im Falle von MW allerdings nicht "nur" bis MAXTHROTTLE sondern bis 2000; sonst könnte die FC bei Vollgas nicht mehr regulierend eingreifen. Die Werte von 1000-2000 sind ja nicht MW-spezifisch sondern werden fast überall im Modellbau verwendet. Wenn die ESC gleichmässig kalibriert wurden kann es jedenfalls nicht an dieser Kalibrierung liegen, wenn der Copter nicht gleichmässig fliegt.
Das die Motoren am Boden unterschiedlich laufen ist zu hinterfragen. Bei eingeschaltetem ACC (Level oder Horizonmode) ist das normal: Der Copter wird nicht 100,0% gerade stehen, sowie ein kleines bischen Gas gegeben wird wird die Steuerung aktiv und versucht den Copter gerade zu stellen.
Wenn der ACC (und auch kein anderer Sensor) nicht aktiv ist (Acromode), dann sollten die Sollwerte, welche die FC an die ESC gibt gleich sein.

Goetz_Cologne · Jan 19, 2014

"Leider nein im WIconf sehe ich die 4 Motore mit unterschiedlichen Werten re hinten u. li vo drehen langsamer bzw. beginnen später zu drehen."

Du meinst also die Werte in der GUI oder das tatsächliche Anlaufen der Motoren?

Diagonal gegenüber höher drehende Motoren heisst, dass die Steuerung gieren möchte.... ...ist der MAG aktiv? Ist er kalibriert?

Mir ist überigens Deine Fehlerbeschreibung vom MP auch nicht klar... ....der Copter ist eine Rolle geflogen, weil der MAG falsche Werte geliefert hat??? m.E. stimmt da was ganz anderes nicht, der MAG hat Einfluss auf das Gieren, nicht auf das Rollen...

Das AIO hat den Nachteil, dass der MAG mit auf dem Board sitzt und somit im Einflussbereich anderer Komponenten. Insbesondere die mit viel A (Lipo und ESC-Leitungen) sollten daher möglichst weit weg und verdrillt geführt werden. Wenn Du den Copter festschnallst und an die GUI hängst, darf der Kompass nicht zucken, wenn Du Ruckartig am Gas spielst (pass bloss auf die Props auf!)

-Ralf- · Jan 19, 2014

Goetz_Cologne hat gesagt.:

Sorry, aber beide Aussagen sind ..... falsch!

Output.cpp (da steht MAXTHROTTLE, und nicht 2000)

Code:

  /****************                normalize the Motors values                ******************/
    maxMotor=motor[0];
    for(i=1; i< NUMBER_MOTOR; i++)
      if (motor[i]>maxMotor) maxMotor=motor[i];
    for(i=0; i< NUMBER_MOTOR; i++) {
      if (maxMotor > MAXTHROTTLE) // this is a way to still have good gyro corrections if at least one motor reaches its max.
        motor[i] -= maxMotor - MAXTHROTTLE;
      motor[i] = constrain(motor[i], conf.minthrottle, MAXTHROTTLE);
      if ((rcData[THROTTLE] < MINCHECK) && !f.BARO_MODE)
      #ifndef MOTOR_STOP
        motor[i] = conf.minthrottle;
      #else
        motor[i] = MINCOMMAND;
      #endif
      if (!f.ARMED)
        motor[i] = MINCOMMAND;
    }

MultiWii.cpp (hier werden die I-Anteile auf 0 gesetzt, wenn das
Gas unter MINCHECK ist; darüber laufen die Motoren ungleich)

Code:

    if (rcData[THROTTLE] <= MINCHECK) {            // THROTTLE at minimum
      #if !defined(FIXEDWING)
        errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0;
        #if PID_CONTROLLER == 1
          errorGyroI_YAW = 0;
        #elif PID_CONTROLLER == 2
          errorGyroI[YAW] = 0;
        #endif
        errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
      #endif
      if (conf.activate[BOXARM] > 0) {             // Arming/Disarming via ARM BOX
        if ( rcOptions[BOXARM] && f.OK_TO_ARM ) go_arm(); else if (f.ARMED) go_disarm();
      }
    }

Goetz_Cologne · Jan 20, 2014

Hallo Ralf,
das ist interessant. Du scheinst Dich im Code gut auszukennen oder ihn zumindest gut lesen zu können, das ist bei mir nur sehr rudimentär der Fall. Meine Aussage oben beruhte mehr auf der Annahme, dass das obere Ende des Steuerbereichs von MW identisch ist wie das obere Ende des angelernten Bereichs der Regler. Als Standardwert in der config.h steht als oberer Calibrierungswert aber explizit 2000, alles andere mache m.E auch keinen Sinn. Ich hatte gedacht, dass der Wert MAXTHROTTLE so gedacht sei, dass dies der maximal vom Piloten per Stickeingabe angenommene Wert darstellt und der restliche Regelbereich von MAXTHROTTLE bis 2000 für MW zur Steuerkorrektur zur Verfügung stehen sollte.
Wenn (wie Dein geposteter Codeausschnitt ja vermuten lässt) der maximal von MW ausgegebene Wert aber MAXTHROTTLE beträgt, dann würde das heissen, dass MW definitiv einen Teil der zur Verfügung stehenden Leistung (Regleröffnung) nicht nutzt. Bei dem Standardwert von 1850 reden wir immerhin von 15%...

Zu Deinem zweiten Codeschnipsel:
Er zeigt (soweit ich das lesen kann), dass die I-Werte auf 0 gesetzt werden, wenn der Gasstick <=MINCHECK ist. Er zeigt aber nicht, das die Motoren zwingend ungleich laufen, wenn das nicht der Fall ist. Nach meinem Verständnis müsste bei Throttle > MINCHECK eine Korrektur durch alle zugeschalteten Sensoren erfolgen - sofern diese einen Korrekturbedarf messen... ...Genau das ist aber doch meine Aussage gewesen, die Du als "...falsch" beschrieben hast.

Bei dem oberen Punkt habe ich das Gefühl, dass wir ggfs. einer möglichen Verbesserung des MW-Codes auf der Spur sind, bei dem untern Punkt bitte ich Dich ausführlicher zu erklären, warum meine Betrachtung falsch ist, vielleicht kommt ja auch hier noch etwas spannendes zu Tage...

-Ralf- · Jan 20, 2014

Hi Goetz,

ja, ich programmier da so ein bischen mit, deshalb kenne ich mich im MWii-Code so leidlich aus.

zu 1)

Richtigerweise gehst du wie folgt vor: Du schaust im GUI, welchen Wert dein
Throttle-Signal maximal erreicht. Diesen Wert trägst du als MAXTHROTTLE ein.
Anschließend kalibrierst du die ESC mit ESC_CALIB_CANNOT_FLY, und du hast
nichts verschenkt.

zu 2)
Der I-Anteil ist ein Fehler, der sich ständig aufaddiert. Oberhalb von MINCHECK
(Default: 1100) werden die I-Anteile frei geschaltet, d.h. sie fangen an, sich zu
addieren. Dein Sensor wird sicherlich eine minimale Abweichung feststellen (leichte
Erschütterung reicht da). Dieser Fehler geht in den I-Anteil. Da dein Copter aber
fest steht und nicht durch Gegenbewegung den Fehler ausgleichen kann, wird im
nächsten Durchlauf der I-Fehler erneut hinzuaddiert. Deine FC versucht nun, dem
stärkeren Fehler auch stärker entgegenzuwirken ... geht nicht, also noch einen drauf
u.s.w.

Kannst du gerne ausprobieren: Gib Gas über 1100 und beobachte, was deine Motoren
machen .... sie laufen weg. Nimm das Gas unter 1100 (I wird auf 0 gesetzt) und sie laufen
gleich. Jetzt machst du einen 2. Test: Nimm die I-Anteile im PID-Controller für Nick, Roll und Yaw
auf 0.000 ...... gib Gas und siehe erstaunt, dass die Motoren gleich laufen.

Es ist völlig normal, dass die Motoren weglaufen, wenn der Copter am Boden steht, Gas
über MINCHECK ist und die I-Anteile nicht auf 0.000 sind.

Goetz_Cologne · Jan 20, 2014

Hi Ralf,
Danke für die Erklärungen, den 2. Punkt habe ich soweit verstanden und abgehakt.

Beim ersten Punkt war ich der Auffassung, dass die "Lehrmeinung" von MW vorsieht, dass man in der GUI kontrolliert, dass die Wege der Funke von 1000-2000 für alle Kanäle gehen und dies durch Anpassungen der Funke so eingestellt wird, nicht anders herum. Nur so wird doch auch der max. mögliche Regelbereich (Abstufung) beibehalten?
Ohne Anpassungen (Verwendung der vorgegebenen Regelwerte) ist es anscheinend im Moment so, dass mit MAXTHROTTLE 1850 und Obergrenze der ESC-Kalibrierung von 2000 150 Regelpunkte am oberen Ende der Regleröffnung verschenkt werden.
Bei ESC_CALIB_CANNOT_FLY steht ja nicht MAXTHROTTLE sondern 2000...

Dem Regler wird beigebracht, dass er bei 2000 100% Öffnung hat, da er nie mehr als 1850 gesendet bekommt, er macht nie ganz auf sondern nur 85% (beim Regelwert von MINCOMMAND = 1000 als Regleruntergrenze). 15% Leistung werden nicht genutzt...?

-Ralf- · Jan 20, 2014

Ja Goetz,

hatte ich übersehen, die 2000 bei ESC_CALIB_CANNOT_FLY muss man durch
MAXTHROTTLE oder den tatsächlichen Wert ersetzen. In meinem (geänderten) Sketch
steht da auch MAXTHROTTLE, im originalem nicht. Danke für den Hinweis.

Und nein, du verschenkst nichts, wenn du die Regler zwischen MINCOMMAND und
MAXTHROTTLE anlernst; er macht ja dann ganz auf oder zu; nur die Regelschritte
sind halt weniger. Und MAXTHROTTLE muss eh über 1900 liegen, sonst greift MAXCHECK
nicht, was als HIGH interpretiert wird (für die AUX-Boxes und Stick-Commands).

Goetz_Cologne · Jan 21, 2014

Hi Ralf,
ich glaube ja, dass Du recht hast, dass der MW-Code tatsächlich nur zwischen MINCOMMAND und MAXTHROTTLE regelt und es ist auch klar, dass keine Power verloren geht, WENN die ESC auf diese Werte kalibriert sind, ABER

- was spricht dagegen den "normalen" oberen Grenzwert von 2000 zu verwenden und so alle Regelschritte zu erhalten

- welchen Sinn macht die Variable MAXTHROTTLE, wenn nicht die Begrenzung der reinen Piloteneingabe

Fakt ist, dass mit Standardwerten genutztes MW bei über die Funke oder über ungeänderten MW-Code kalibrierten ESC 15% Leistung verschenkt, wofür kein Grund bekannt ist.

Dein Ansatz den Wert bei der ESC-Kalibrierung von 2000 durch MAXTHROTTLE zu ersetzen macht m.E. nur dann Sinn, wenn es Funken gibt, die man nicht auf 2000 einstellen kann (gibts sowas noch?); sonst wäre der Entfall der Variable MAXTHROTTLE und Ersatz durch den hart codierten Wert 2000 sinnvoller, da die Regelschritte erhalten bleiben.
Vielleicht ist der Ansatz, mit MAXTHROTTLE lediglich die Piloteneingabe zu begrenzen um bei maximaler Stickeingabe noch Steuerreserven zu haben eine sinnvolle Entwicklung die in den Codes eingehen könnte?

Das der Wert MAXTHROTTLE über 1900 liegen muss um Stick-Commandos zu ermöglichen kann nicht sein. Seit einigen Versionen liegt die Standardvorgabe dafür bei 1850 und die Stick-Commands funktionieren trotzdem.

Bitte betrachte meine Posts nicht als Meckern, ich möchte als Nicht-Coder nur mithelfen das tolle Projekt weiter zu verbessern.

Bearbeitung: Ich habe doch mal versucht im Code zu suchen und habe in multiwii.cpp folgendes gefunden:
tmp = constrain(rcData[THROTTLE],MINCHECK,2000);
tmp = (uint32_t)(tmp-MINCHECK)*2559/(2000-MINCHECK); // [MINCHECK;2000] -> [0;2559]
tmp2 = tmp/256; // range [0;9]
rcCommand[THROTTLE] = lookupThrottleRC[tmp2] + (tmp-tmp2*256) * (lookupThrottleRC[tmp2+1]-lookupThrottleRC[tmp2]) / 256; // [0;2559] -> expo -> [conf.minthrottle;MAXTHROTTLE]

Würde es da nicht genügen in der ersten Zeile die 2000 durch MAXTHROTTLE zu ersetzen?

-Ralf- · Jan 21, 2014

Da habe ich mich unklar ausgedrückt ..... für die Highschwelle ist MAXCHECK
ausschlaggebend, wo MAXTHROTTLE steht, wird gar nicht ausgewertet, sondern
das tatsächliche Throttle-Signal. Und das muss >= 1900 (Default) sein.

Und ja, in letzter Zeit sind tatsächlich öfters RC-Anlagen (preiswerte 4-6 Kanal)
in Erscheinung getreten, die keine 2000 als oberen Wert erreichen.

Du wirst an verschiedenen Stellen hartcodierte Werte finden. Teilweise
ist das historisch und könnte geändert werden, teilweise aber auch beabsichtigt,
um nachfolgende Rechnereien in bestimmten Grenzen zu halten.

Es macht imho überhaupt keinen Sinn, die Piloteneingaben auf Werte zu
beschränken, die unterhalb der Reglermöglichkeiten liegen. Der Pilot soll
(bei nur geringen Sensorkorrekturen) soviel wie möglich selbst abrufen
können. Alles andere wäre eine Kastration.

Versuch Crius AIO mit Multiwii zu testen - kein upload möglich!

Neuer Benutzer

Erfahrener Benutzer

Neuer Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Neuer Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Neuer Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer