pre 2.4 version r1739

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

pre 2.4 version r1739

Post by Alexinparis »

So, let's try again to prepare the 2.4 with this intermediate dev release

Here is a draft for the release note:

GPS:
    The main change in this version is for sure the code brought by EOSBandi regarding navigation (supported long time as a standolone MultiWii 2.3navi B7) . Thanks to this major contribution, MultiWii can now navigate trought multiple WPs in an autonomous way.
    The documentation about all define option can be found in this post:
    viewtopic.php?f=8&t=3989
    For the moment, at least 2 GUI can support this code to program a mission: WinGui from EOSBandi / EZ-GUI from Ezio. No support in java GUI MultiWiiConf.
    In order to work with current dev WinGUI, the version number should be switched back to 230.
    otherwise an error message will occur.
    in MultiWii.h , line: #define VERSION 230
    Do not forget to activate #define USE_MSP_WP to be able to use waypoints.

    The overall code without GPS is much shorter. However due to the change on GPS code, it is no more compatible with a 32u4 proc.
    The GPS code without nav might still work on 328p proc.
    A mega proc is mandatory to benefit from all the GPS functionalities.
    dissociate frame parsing & frame computation
    I2C GPS is no more used as an extension with nav computation. It is now supported as a simple GPS device, and all computations stay in the FC, exactly like Serial GPS device.
    GPS Serial frame parsing is now part of generic Serial decoding code
    UBLOX GPS frame parsing improvement

IMU computation:
    mostly optimization on computation time not visible for end users: less float and more 16bit integer where it's possible / some specific avr asm multiplication.
    better accuracy InvSqrt
    heading is computed even with no mag
    hungry tasks has been reduced or divided in order to minimize the jitter of loop time. With this improvement, a constant loop time is set a little bit higher than the average and default to 2.8ms.

ACC:
    Nunchuk is no more suported

Baro MS561101:
    a little bit paradoxal regarding other portion of code approach in multiwii, but float computation tooked from APM appears to be shorter and faster with a minimal approximation.
    computation time smoothed thanks to a task split
    #define ALTITUDE_RESET_ON_ARM option is added
    note the baro is still always reset when doing a gyro calibration

I2C:
    no more speed change on the fly: all sensors are default to 400kHz.
    The only exception is when a legacy WMP is still used with a 100kHz speed. So no need to bother any longer about this speed if you don't own a genuine WMP.
    In case of I2C errors at the init stage, initialization occurs up to 5 times. This should prevent some remaining I2C errors.

Brushed motor option:
    brushed motors option on 32u4 proc at 8/16/32 kHz

RX receiver:
    SUMD RX type introduction
    SBUS improvement / SBUS signal scaling to match other receiver range
    code factorization for all Serial type RX (Spektrum/SUMD/SBUS)
    adjustable averaging sample (AVERAGING_ARRAY_LENGTH) for non Serial RX. For Serial RX, the averaging code is removed because the signal is already natively digital.
    Serial RX should now be usable with no glitch during LCD conf
    RSSI injection on a rc channel

MSP:
    MSP message for ACC TRIM (not used in java MultiWiiConf)
    MSP message for cells voltage
    MSP messages for GPS navigation
    remove MSP ack for MSP_SET_RAW_RC

Sonar:
    fix Devantech SRFxx code that was broken some time ago. But still no code integrated for alt lock using sonar.

Heli:
    experimental : piro compensation
    experimental : heli yaw precomp dependant on collective pitch
    experimental : better tail lock tacking intoo account collective pitch

Voltage:
    compute watts
    experimental : individual cells voltage monitoring (alarm portion undone yet)

reference version to compile sketch:
- windows version of Arduino IDE 1.0.6
- processing 1.5.1 with modified verison of ControlP5 to remove blue triangles in value box

download link:
https://code.google.com/p/multiwii/
https://drive.google.com/uc?export=down ... TJRTG5JVmM

Please use this post to relate feedbacks. What works well, what does not work.
Please don't use this post as a whishlist.

User avatar
stronnag
Posts: 114
Joined: Thu Oct 24, 2013 9:32 pm
Location: New Forest, England
Contact:

Re: pre 2.4 version r1739

Post by stronnag »

Alexinparis wrote:So, let's try again to prepare the 2.4 with this intermediate dev release

Here is a draft for the release note:

GPS:
    The main change in this version is for sure the code brought by EOSBandi regarding navigation (supported long time as a standolone MultiWii 2.3navi B7) . Thanks to this major contribution, MultiWii can now navigate trought multiple WPs in an autonomous way.
    The documentation about all define option can be found in this post:
    viewtopic.php?f=8&t=3989
    For the moment, at least 2 GUI can support this code to program a mission: WinGui from EOSBandi / EZ-GUI from Ezio. No support in java GUI MultiWiiConf.


Alas, you omit mwp, which also supports the MW 2.4 navigation protocols in a nice UI for free operating systems.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: pre 2.4 version r1739

Post by EOSBandi »

A 2.4 WinGUI will be released on next week :)

skoubri
Posts: 18
Joined: Sun Mar 03, 2013 1:24 pm

Re: pre 2.4 version r1739

Post by skoubri »

a BIG THANKS!!! :D

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Re: pre 2.4 version r1739

Post by ezio »

Can MSP_SET_ACC_TRIM and MSP_ACC_TRIM be modified to the baseflight/cleanflight standard ?

Right now the Pitch and Roll and swapped.

from cleanflight source:

Code: Select all

  case MSP_SET_ACC_TRIM:
        currentProfile->accelerometerTrims.values.pitch = read16();
        currentProfile->accelerometerTrims.values.roll  = read16();
        break;

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: pre 2.4 version r1739

Post by Hamburger »

what exactly is
ezio wrote: baseflight/cleanflight standard

Mirandor
Posts: 1
Joined: Wed Jan 28, 2015 7:52 pm

Re: pre 2.4 version r1739

Post by Mirandor »

Hi all,

When i want to use I2C_GPS by uncommenting the associated line in config.h, i get a compilation error

Code: Select all

Protocol.cpp: In function 'void evaluateOtherData(uint8_t)':
Protocol.cpp:736: error: 'GPS_SERIAL' was not declared in this scope

PatrikE
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: pre 2.4 version r1739

Post by PatrikE »

Mirandor wrote:Hi all,

When i want to use I2C_GPS by uncommenting the associated line in config.h, i get a compilation error

Code: Select all

Protocol.cpp: In function 'void evaluateOtherData(uint8_t)':
Protocol.cpp:736: error: 'GPS_SERIAL' was not declared in this scope


I have committed a fix already in svn.
But you can comment row 736 in Protocol.cpp until next Pre 2.4 version is released.

Code: Select all

 // if (CURRENTPORT == GPS_SERIAL) return;

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

pre 2.4 version r1739

Post by ezio »

Hamburger wrote:what exactly is
ezio wrote: baseflight/cleanflight standard

Ok I have used wrong words.
I just waned to say that trims was implemented first in baseflight so why multiwii can't handle them in the same way?
Multiwii, baseflight and cleanflight are using the same protocol so the commands should be the same on all these platforms.

I'm asking to change two lines of code. Is it to much?

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1739

Post by Alexinparis »

stronnag wrote:
Alas, you omit mwp, which also supports the MW 2.4 navigation protocols in a nice UI for free operating systems.


ok, I will add it also in the release note

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1739

Post by Alexinparis »

ezio wrote:Can MSP_SET_ACC_TRIM and MSP_ACC_TRIM be modified to the baseflight/cleanflight standard ?

Right now the Pitch and Roll and swapped.

from cleanflight source:

Code: Select all

  case MSP_SET_ACC_TRIM:
        currentProfile->accelerometerTrims.values.pitch = read16();
        currentProfile->accelerometerTrims.values.roll  = read16();
        break;


I've just made a commit.
It was a little bit more complicated than swapping lines because the whole struct is generally used when possible to transfer message, and PITCH follows ROLL in the struct.
Tell me if it's ok (only change in Protocol.cpp)

PatrikE
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: pre 2.4 version r1739

Post by PatrikE »

EOSBandi wrote:A 2.4 WinGUI will be released on next week :)


Is it possible to get WinGUI to run without USE_MSP_WP defined?
It doesnt work in the current version WinGUI 2.3 pre10 for navi B7.

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

pre 2.4 version r1739

Post by ezio »

Alexinparis wrote:
ezio wrote:Can MSP_SET_ACC_TRIM and MSP_ACC_TRIM be modified to the baseflight/cleanflight standard ?

Right now the Pitch and Roll and swapped.

from cleanflight source:

Code: Select all

  case MSP_SET_ACC_TRIM:
        currentProfile->accelerometerTrims.values.pitch = read16();
        currentProfile->accelerometerTrims.values.roll  = read16();
        break;


I've just made a commit.
It was a little bit more complicated than swapping lines because the whole struct is generally used when possible to transfer message, and PITCH follows ROLL in the struct.
Tell me if it's ok (only change in Protocol.cpp)

Thank you Alex

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1739

Post by Leo »

EOSBandi wrote:A 2.4 WinGUI will be released on next week :)


Just thought I'd mention it's already Thursday today ;)

mbeerer
Posts: 12
Joined: Fri Feb 06, 2015 6:36 am

Re: pre 2.4 version r1739

Post by mbeerer »

I'm setting up a Witespy MultiWii Pro Ez3.0 Black edition with the I2C remote magnetometer. The magnetometer worked fine with 2.3 but does not work with 2.4r1739. Any thoughts on if there is a bug, or was there a change to I2C interface that requires something defined in config.h?

helikalle
Posts: 4
Joined: Wed Jan 21, 2015 3:51 pm
Location: Germany

Re: pre 2.4 version r1739

Post by helikalle »

I had some trouble with the extended aux states. For example: switching on RC-channel 7 (AUX3) around the 1500us-position activates HORIZON/BARO/MAG but there where no activated checkboxes on AUX3. After some googleing i found a solution in "http://www.multiwii.com/forum/viewtopic.php?f=8&t=5310". The described declaration from "auxState" with "uint32_t" worked perfectly for me. I am not a programmer. So a code-specialist like EOSBani or Alexinparis should have al look at this item.

Greetings from Germany

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: pre 2.4 version r1739

Post by EOSBandi »

Leo wrote:
EOSBandi wrote:A 2.4 WinGUI will be released on next week :)


Just thought I'd mention it's already Thursday today ;)

Stay Tuned :D:D:D

GUSHELFER
Posts: 14
Joined: Mon Apr 07, 2014 5:31 pm

Re: pre 2.4 version r1739

Post by GUSHELFER »

EOSBandi wrote:
Leo wrote:
EOSBandi wrote:A 2.4 WinGUI will be released on next week :)


Just thought I'd mention it's already Thursday today ;)

Stay Tuned :D:D:D



11-02....... sigo atento tambien :shock:

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1739

Post by Alexinparis »

mbeerer wrote:I'm setting up a Witespy MultiWii Pro Ez3.0 Black edition with the I2C remote magnetometer. The magnetometer worked fine with 2.3 but does not work with 2.4r1739. Any thoughts on if there is a bug, or was there a change to I2C interface that requires something defined in config.h?


I think it's related to #define MPU6050_I2C_AUX_MASTER
that should not be defined for a remote mag

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1739

Post by Alexinparis »

helikalle wrote:I had some trouble with the extended aux states. For example: switching on RC-channel 7 (AUX3) around the 1500us-position activates HORIZON/BARO/MAG but there where no activated checkboxes on AUX3. After some googleing i found a solution in "http://www.multiwii.com/forum/viewtopic.php?f=8&t=5310". The described declaration from "auxState" with "uint32_t" worked perfectly for me. I am not a programmer. So a code-specialist like EOSBani or Alexinparis should have al look at this item.

Greetings from Germany


I don't understand your concern as it seems to be corrected in r1739

helikalle
Posts: 4
Joined: Wed Jan 21, 2015 3:51 pm
Location: Germany

Re: pre 2.4 version r1739

Post by helikalle »

Alexinparis wrote:
helikalle wrote:I had some trouble with the extended aux states. For example: switching on RC-channel 7 (AUX3) around the 1500us-position activates HORIZON/BARO/MAG but there where no activated checkboxes on AUX3. After some googleing i found a solution in "http://www.multiwii.com/forum/viewtopic.php?f=8&t=5310". The described declaration from "auxState" with "uint32_t" worked perfectly for me. I am not a programmer. So a code-specialist like EOSBandi or Alexinparis should have al look at this item.

Greetings from Germany


I don't understand your concern as it seems to be corrected in r1739



Ok. To make sure there is no fault by myself with undeleted eeprom i had downloaded Version r1739 again, made an eeprom clear and flashed r1739 on my board. Same behaviour as described before. When changing rc values on AUX3(Chanel 7) i had unwanted mode Switches around the 1500us Position. BARO, MAG and CAMSTAB are set unwanted.
When i Change the code in multiwii.cpp:

Code: Select all

    #if defined(EXTENDED_AUX_STATES)
    uint32_t auxState = 0;
    for(i=0;i<4;i++)
      auxState |= (rcData[AUX1+i]<1230)<<(6*i) |
      (1231<rcData[AUX1+i] && rcData[AUX1+i]<1360)<<(6*i+1) |
      (1361<rcData[AUX1+i] && rcData[AUX1+i]<1490)<<(6*i+2) |
      (1491<rcData[AUX1+i] && rcData[AUX1+i]<1620)<<(6*i+3) |
      (1621<rcData[AUX1+i] && rcData[AUX1+i]<1749)<<(6*i+4) |
      (rcData[AUX1+i]>1750)<<(6*i+5);
    #else

to

Code: Select all

 #if defined(EXTENDED_AUX_STATES)
    uint32_t auxState = 0;
    for(i=0;i<4;i++)
      auxState |= (uint32_t)(rcData[AUX1+i]<=1230)<<(6*i) |
      (uint32_t)(1230<rcData[AUX1+i] && rcData[AUX1+i]<=1360)<<(6*i+1) |
      (uint32_t)(1360<rcData[AUX1+i] && rcData[AUX1+i]<=1490)<<(6*i+2) |
      (uint32_t)(1490<rcData[AUX1+i] && rcData[AUX1+i]<=1620)<<(6*i+3) |
      (uint32_t)(1620<rcData[AUX1+i] && rcData[AUX1+i]<=1750)<<(6*i+4) |
      (uint32_t)(rcData[AUX1+i]>1750)<<(6*i+5);
#else

i have no unwanted mode changes. But: The cycle time raises about 500 (~3200 before, ~3700 after).

Any suggestions?

Helikalle

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1739

Post by Alexinparis »

helikalle wrote:Ok. To make sure there is no fault by myself with undeleted eeprom i had downloaded Version r1739 again, made an eeprom clear and flashed r1739 on my board. Same behaviour as described before. When changing rc values on AUX3(Chanel 7) i had unwanted mode Switches around the 1500us Position. BARO, MAG and CAMSTAB are set unwanted.
When i Change the code in multiwii.cpp:
...
i have no unwanted mode changes. But: The cycle time raises about 500 (~3200 before, ~3700 after).

Any suggestions?

Helikalle


ok sorry I didn't look at the right place.
you are perfectly right, a uint32_t cast is mandatory here.
just corrected in r1743

gmohr
Posts: 2
Joined: Sat Feb 14, 2015 8:31 am

Re: pre 2.4 version r1739

Post by gmohr »

Can someone tell me if I am doing something wrong. With new release r1739 and r1743 I find that my gps switch does not activate. All is ok with 2.3 release.
When I throw my gps aux, (aux 3) level, mag , etc ligts up but not gps or gps home. (same switches in multiwii 2.3 release lights them up)
I have a multiwii pro with a ublox gps (mtk gps broken)

ericolsen01
Posts: 1
Joined: Sun Feb 15, 2015 4:48 pm

Re: pre 2.4 version r1739

Post by ericolsen01 »

Hello to Everyone - Thanks to all for doing awesome work with the updates. Got r1739 loaded and working with the WinGUI_2.3pre10(b7).

One thing - the POI doesn't seem to work. I tried to setting a POI before each waypoint, as well as just one at the beginning with no luck.

Is there something I may be setting wrong?

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1739

Post by Leo »

I'm curious... What's holding back the release of 2.4 and WinGui 2.4 ?

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1739

Post by Leo »

ericolsen01 wrote:Hello to Everyone - Thanks to all for doing awesome work with the updates. Got r1739 loaded and working with the WinGUI_2.3pre10(b7).

One thing - the POI doesn't seem to work. I tried to setting a POI before each waypoint, as well as just one at the beginning with no luck.

Is there something I may be setting wrong?

Maybe this thread (http://www.multiwii.com/forum/viewtopic.php?f=8&t=3989&start=850) may answer your question?

handsomejackuk
Posts: 97
Joined: Mon Sep 08, 2014 12:25 am

Re: pre 2.4 version r1739

Post by handsomejackuk »

Just curious how is this running on atmega 328p mpu's thats all i have on my quad my home built controller... i did try a while back but it seemed very unreliable...

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1739

Post by Leo »

It should work fine without navigation enabled. I had it running on my old board.

handsomejackuk
Posts: 97
Joined: Mon Sep 08, 2014 12:25 am

Re: pre 2.4 version r1739

Post by handsomejackuk »

so no gps at all... ?

i not to concerned about waypoints, but position hold, and rth would be good... any tips to reducing the sketch size..?

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1739

Post by Leo »

Phold and RTH will work just don't set up navigation.

handsomejackuk
Posts: 97
Joined: Mon Sep 08, 2014 12:25 am

Re: pre 2.4 version r1739

Post by handsomejackuk »

ok thanks Leo....

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1739

Post by Leo »


User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

we got a problem - please hold v2.4

Post by Hamburger »

repost -was in r1729 thread, sorry.

I think we got a problem with VBAT code.
analogRead() maps the range of [0 ; 5] Volts input to values of [0 ; 1023].
But with our current code (simplified) :

Code: Select all

      uint16_t v = analogRead(V_BATPIN);
        analog.vbat = (v*16) / conf.vbatscale; // result is Vbatt in 0.1V steps

the scaling divisor conf.vbatscale is an uint8_t, so in the range of [0 ; 255].

In effect, for a single cell we want to measure up to 4.2V, which becomes v=860 with analogRead() - at least in theory for a perfect 5V driven board.
We want analog.vbat to be 42 ( <=> 4.2Volts), so which value of conf.vbatscale could do that?
Simple math yields conf.vbatscale = v*16/analog.vbat or in our case conf.vbatscale = 860 * 16 / 42 = 327.
But 327 is beyond what uint8_t can represent!

This has not shown up in the past because single cell systems are not widespread and for batteries with more cells the divisors were chosen to reach the working range. To make it worse, in my tests with various boards driven from ESC-BECs I have seen variations of the theoretical 5V supply which result in another distortion of the analogRead() range which in some cases makes things even worse.

I see the following options:
a) lower the multiplier from 16 to 8 - this will force everyone to retune conf.vbatscale to about half of original value - also loose one bit of precision for tuning
b) make the multiplier a tunable define with preset 16 - no change for most users; the unlucky users can alter the preset to 8 and be happy
c) rewrite the VBAT code, possibly turn vbatscale into a linear factor instead of a divisor (this has irritated some users in the past);
d) make vbatscale 16 bit [0 ; 64k]

With being so close to release I vote for option b)
Opinions, comments?

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1739

Post by Alexinparis »

Hi,

I would opt equally for a) or b)
and if b), only a #define, no protocol change
c) a linear factor is probably more indicated for what we call a scale (a proportional factor), but the current principle is ok for me (a/b or b/a, it's just a question of documentation)
d) is a nogo (impact on protocol)

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1739

Post by Leo »

Alex, please also take a look at this option concerning BARO and GPS Hold: http://www.multiwii.com/forum/viewtopic.php?f=8&t=5852&start=50#p61959

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: pre 2.4 version r1739

Post by Hamburger »

Alexinparis wrote:Hi,

I would opt equally for a) or b)
and if b), only a #define, no protocol change
c) a linear factor is probably more indicated for what we call a scale (a proportional factor), but the current principle is ok for me (a/b or b/a, it's just a question of documentation)
d) is a nogo (impact on protocol)


ok, cool. option b) it is then.
b) make the multiplier a tunable define with preset 16 - no change for most users; the unlucky users can alter the preset to 8 and be happy.

I will clean up and commit soon.

Thomas_R.
Posts: 2
Joined: Sun Mar 08, 2015 10:09 pm

Re: pre 2.4 version r1739

Post by Thomas_R. »

Hi,
today my first steps with the pre 2.4 (r1739).

in MultiWii.h , line: #define VERSION 230
Do not forget to activate #define USE_MSP_WP to be able to use waypoints.

Done.

But GPS itself is not configured and attached yet.
Everything else is configured (very similar to the 2.3 configuration) for a QUADX with the AIOP board.
EEPROM was cleared before uploading for all 4096 bytes.

The pre10 for navi B7 started successfully. But a connect is not possible. Lot of exceptions and then it crashed completly.

Anything known like this?

Best
Thomas

Thomas_R.
Posts: 2
Joined: Sun Mar 08, 2015 10:09 pm

Re: pre 2.4 version r1739

Post by Thomas_R. »

Sorry, comment was in German. ;-)

I attached the first exception i can ses.

Code: Select all

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ArgumentOutOfRangeException: Value of '0' is not valid for 'Value'. 'Value' should be between 'Minimum' and 'Maximum'.
Parameter name: Value
   at System.Windows.Forms.NumericUpDown.set_Value(Decimal value)
   at MultiWiiWinGUI.mainGUI.update_gui() in z:\VS-projects\mw-wingui\MultiWiiWinGUI\mainGUI.cs:line 2177
   at MultiWiiWinGUI.mainGUI.b_connect_Click(Object sender, EventArgs e) in z:\VS-projects\mw-wingui\MultiWiiWinGUI\communication.cs:line 240
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 4.0.0.0
    Win32 Version: 4.0.30319.18444 built by: FX451RTMGDR
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
MultiWiiWinGUI
    Assembly Version: 2.3.5160.23771
    Win32 Version: 2.3.0.0
    CodeBase: file:///C:/MultiWii/wingui_2.3_pre10_for_navi_B7/WinGUI_2.3pre10(b7)/MultiWiiWinGUI.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 4.0.0.0
    Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
    Assembly Version: 4.0.0.0
    Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System
    Assembly Version: 4.0.0.0
    Win32 Version: 4.0.30319.34238 built by: FX452RTMGDR
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
GMap.NET.Core
    Assembly Version: 1.7.0.0
    Win32 Version: 1.7
    CodeBase: file:///C:/MultiWii/wingui_2.3_pre10_for_navi_B7/WinGUI_2.3pre10(b7)/GMap.NET.Core.DLL
----------------------------------------
GMap.NET.WindowsForms
    Assembly Version: 1.7.0.0
    Win32 Version: 1.7
    CodeBase: file:///C:/MultiWii/wingui_2.3_pre10_for_navi_B7/WinGUI_2.3pre10(b7)/GMap.NET.WindowsForms.DLL
----------------------------------------
ZedGraph
    Assembly Version: 5.1.2.878
    Win32 Version: 5.1.2.878
    CodeBase: file:///C:/MultiWii/wingui_2.3_pre10_for_navi_B7/WinGUI_2.3pre10(b7)/ZedGraph.DLL
----------------------------------------
AForge.Controls
    Assembly Version: 2.2.3.0
    Win32 Version: 2.2.3.0
    CodeBase: file:///C:/MultiWii/wingui_2.3_pre10_for_navi_B7/WinGUI_2.3pre10(b7)/AForge.Controls.DLL
----------------------------------------
AForge.Video
    Assembly Version: 2.2.3.0
    Win32 Version: 2.2.3.0
    CodeBase: file:///C:/MultiWii/wingui_2.3_pre10_for_navi_B7/WinGUI_2.3pre10(b7)/AForge.Video.DLL
----------------------------------------
System.Configuration
    Assembly Version: 4.0.0.0
    Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
    Assembly Version: 4.0.0.0
    Win32 Version: 4.0.30319.34234 built by: FX452RTMGDR
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Data.SQLite
    Assembly Version: 1.0.84.0
    Win32 Version: 1.0.84.0
    CodeBase: file:///C:/Users/thomas/AppData/Local/GMap.NET/DllCache/SQLite_v84_NET4_x86/System.Data.SQLite.DLL
----------------------------------------
System.Data
    Assembly Version: 4.0.0.0
    Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll
----------------------------------------
System.Core
    Assembly Version: 4.0.0.0
    Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Transactions
    Assembly Version: 4.0.0.0
    Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Transactions/v4.0_4.0.0.0__b77a5c561934e089/System.Transactions.dll
----------------------------------------
AForge.Video.DirectShow
    Assembly Version: 2.2.3.0
    Win32 Version: 2.2.3.0
    CodeBase: file:///C:/MultiWii/wingui_2.3_pre10_for_navi_B7/WinGUI_2.3pre10(b7)/AForge.Video.DirectShow.DLL
----------------------------------------
System.Speech
    Assembly Version: 4.0.0.0
    Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Speech/v4.0_4.0.0.0__31bf3856ad364e35/System.Speech.dll
----------------------------------------
System.EnterpriseServices
    Assembly Version: 4.0.0.0
    Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.


Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1739

Post by Alexinparis »

Leo wrote:Alex, please also take a look at this option concerning BARO and GPS Hold: http://www.multiwii.com/forum/viewtopic.php?f=8&t=5852&start=50#p61959


Hi,

I follow the GPS baro logic, and it seems to be already covered by the #define NAV_TAKEOVER_BARO 1 option
if #define 0 the baro can be dissociated form GPS manually at any time, then GPS HOLD can be dissociated from ALT HOLD

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1739

Post by Leo »

Thank you. I learnt something new again :)

Solarwater
Posts: 9
Joined: Wed Mar 04, 2015 2:40 am
Location: Detroit metro

Re: pre 2.4 version r1739

Post by Solarwater »

Alexinparis wrote:
Leo wrote:Alex, please also take a look at this option concerning BARO and GPS Hold: http://www.multiwii.com/forum/viewtopic.php?f=8&t=5852&start=50#p61959


Hi,

I follow the GPS baro logic, and it seems to be already covered by the #define NAV_TAKEOVER_BARO 1 option
if #define 0 the baro can be dissociated form GPS manually at any time, then GPS HOLD can be dissociated from ALT HOLD


Hi Alex, I did find that as a potential fix, but it doesn't give me the results I want. We need Baro support in rth/land/mission for them to work properly. Hold does not require it, but can be used with it. In the code, there is f.GPS_BARO_MODE set on or off in every gps mode except for hold. My problem is if I am flying in gps hold, switch to rth, and then switch back to hold, baro will be enabled even if I wasn't using it before. This can not be the correct intention of the Baro takeover system.

By just adding the single line f.GPS_BARO_MODE = false; to the hold section, it becomes switchable again. I can't think of a condition that would require baro takeover for pos hold. This "lock in" condition only occurs when you switch to rth/land/mission, and then back to hold.

I also don't want to disable the takeover system since I need it for features like the fence, where I may be flying without baro on when I hit the fence, i would want it taken over so it will rth at a safe altitude.

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1739

Post by Leo »

I've added the option "f.GPS_BARO_MODE = false;" as described and took the QC out for some tests. I didn't encounter any problems but need to do more flight variations.
However I would greatly appreciate if the codes could take a closer look at it as I don't know if any other functions within MultiWii will have a negative effect. I do feel a little uncomfortable using it ATM.

On a side note: Before I had BARO active with GPS Hold. Since it is now deactivated and BARO is configured to a separate switch on the remote I need to remember to switch off both functions.
A couple of time this caught me off guard as I deactivated BARO but forgot to deactivate GPS Hold which made me think my trimmings were all off as the QC didn't want stay level when I was trying to fly it away :D

dzakarya
Posts: 2
Joined: Thu Mar 12, 2015 5:07 am

Re: pre 2.4 version r1739

Post by dzakarya »

is there anyone know how to setup altitude hold in this version?

User avatar
haydent
Posts: 583
Joined: Sun Jun 17, 2012 1:35 am
Location: NSW, AU

Re: pre 2.4 version r1739

Post by haydent »

Hi guys, not to hijack this thread, though it is the active dev one at moment, i have prepared a newly integrated patch against r1745 of the frsky s.port telemetry code that im hoping to get merged into shared. its here, and can discuss it there not to take up space here please : viewtopic.php?f=8&t=5164&p=62141#p62141

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: pre 2.4 version r1739

Post by Hamburger »

for release notes, please:
- remove Heli.experimental : piro compensation (was only suggested for pid.controller=2, never merged)
- add LCD.lcd03 over serial support added

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1739

Post by Alexinparis »

Solarwater wrote:Hi Alex, I did find that as a potential fix, but it doesn't give me the results I want. We need Baro support in rth/land/mission for them to work properly. Hold does not require it, but can be used with it. In the code, there is f.GPS_BARO_MODE set on or off in every gps mode except for hold. My problem is if I am flying in gps hold, switch to rth, and then switch back to hold, baro will be enabled even if I wasn't using it before. This can not be the correct intention of the Baro takeover system.

By just adding the single line f.GPS_BARO_MODE = false; to the hold section, it becomes switchable again. I can't think of a condition that would require baro takeover for pos hold. This "lock in" condition only occurs when you switch to rth/land/mission, and then back to hold.

I also don't want to disable the takeover system since I need it for features like the fence, where I may be flying without baro on when I hit the fence, i would want it taken over so it will rth at a safe altitude.


Hi,

Ok, I understand better the concern. especially: "My problem is if I am flying in gps hold, switch to rth, and then switch back to hold, baro will be enabled even if I wasn't using it before."
This should be deterministic and not dependent with the previous activation. I will add the line for BOXGPSHOLD box in the code as you suggest.
That reminds me a video I did a long time ago with a mikrokopter flying in a virtual column with gps hold and no baro.
http://www.youtube.com/watch?v=emo8RepFxdE

@Leo:
you still have the option to activate both box baro+hold with the same switch. the result will be the same.

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1739

Post by Leo »

Alexinparis wrote:@Leo:
you still have the option to activate both box baro+hold with the same switch. the result will be the same.


Thanks. I wasn't aware that one can change altitude while in Baro mode.

@ALL: Looks like 2.4 is finally out, at least in the source tree :)

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1739

Post by Leo »

EOSBandi wrote:A 2.4 WinGUI will be released on next week :)

Cough cough.... :D

Post Reply