MultiWii

Posted: **Sat Jan 24, 2015 6:21 pm**

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

Here is a draft for the release note:

GPS:

viewtopic.php?f=8&t=3989

IMU computation:

ACC:

Baro MS561101:

I2C:

Brushed motor option:

viewtopic.php?f=8&t=3635&p=36883#p36877

RX receiver:

MSP:

Sonar:

Heli:

Voltage:

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.

Posted: **Sat Jan 24, 2015 7:23 pm**

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.

Posted: **Sun Jan 25, 2015 10:28 pm**

A 2.4 WinGUI will be released on next week

Posted: **Mon Jan 26, 2015 10:12 am**

a BIG THANKS!!!

Posted: **Wed Jan 28, 2015 3:29 am**

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;

Posted: **Wed Jan 28, 2015 6:38 pm**

what exactly is

ezio wrote: baseflight/cleanflight standard

Posted: **Wed Jan 28, 2015 8:01 pm**

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

Posted: **Wed Jan 28, 2015 9:04 pm**

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;

Posted: **Thu Jan 29, 2015 6:54 am**

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?

Posted: **Sat Jan 31, 2015 5:25 pm**

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

Posted: **Sat Jan 31, 2015 5:32 pm**

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)

Posted: **Sat Jan 31, 2015 9:30 pm**

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.

Posted: **Sat Jan 31, 2015 9:48 pm**

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

Posted: **Thu Feb 05, 2015 1:24 pm**

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

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

Posted: **Fri Feb 06, 2015 6:43 am**

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?

Posted: **Fri Feb 06, 2015 4:35 pm**

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

Posted: **Sun Feb 08, 2015 4:46 pm**

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

Posted: **Wed Feb 11, 2015 3:23 pm**

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

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

Posted: **Thu Feb 12, 2015 11:56 pm**

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

Posted: **Thu Feb 12, 2015 11:58 pm**

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

Posted: **Fri Feb 13, 2015 7:20 pm**

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

Posted: **Sat Feb 14, 2015 12:07 am**

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

Posted: **Sun Feb 15, 2015 7:26 pm**

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)

Posted: **Sun Feb 15, 2015 8:46 pm**

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?

Posted: **Sat Feb 21, 2015 7:07 pm**

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

Posted: **Sat Feb 21, 2015 7:09 pm**

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?

Posted: **Sat Feb 21, 2015 7:34 pm**

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...

Posted: **Sat Feb 21, 2015 7:40 pm**

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

Posted: **Sat Feb 21, 2015 9:49 pm**

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..?

Posted: **Sat Feb 21, 2015 10:11 pm**

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

Posted: **Sat Feb 21, 2015 10:24 pm**

ok thanks Leo....

Posted: **Sat Mar 07, 2015 10:20 am**

Possible issue: http://www.multiwii.com/forum/viewtopic.php?f=8&t=5852&start=50#p62032

Posted: **Sat Mar 07, 2015 10:38 am**

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?

Posted: **Sat Mar 07, 2015 11:02 am**

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)

Posted: **Sat Mar 07, 2015 11:15 am**

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

Posted: **Sat Mar 07, 2015 11:20 am**

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.

Posted: **Sun Mar 08, 2015 10:16 pm**

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

Posted: **Sun Mar 08, 2015 10:56 pm**

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.

Posted: **Tue Mar 10, 2015 12:36 am**

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

Posted: **Tue Mar 10, 2015 6:43 am**

Thank you. I learnt something new again

Posted: **Tue Mar 10, 2015 4:04 pm**

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.

Posted: **Thu Mar 12, 2015 8:05 am**

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

Posted: **Thu Mar 12, 2015 10:23 am**

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

Posted: **Thu Mar 12, 2015 10:32 am**

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

Posted: **Fri Mar 13, 2015 12:41 am**

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

Posted: **Fri Mar 13, 2015 11:56 pm**

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.

Posted: **Sat Mar 14, 2015 5:04 pm**

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

Posted: **Sun Mar 15, 2015 11:26 am**

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

Cough cough....

MultiWii

pre 2.4 version r1739

pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

we got a problem - please hold v2.4

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739

Re: pre 2.4 version r1739