pre 2.4 version r1729

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

pre 2.4 version r1729

Post by Alexinparis »

It's been a long time since a new version is not released.
So, let's try to prepare the 2.4.

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

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 : better tail lock tacking intoo account collective pitch

Voltage:
    compute watts


As google code do not allow anymore to upload download files, I will try here a new way to share multiwii binaries: bittorrent.
The torrent file is attached to this post.
I think it could be a good way for such a project. We will see if it's good enough or not.

Please use this post to relate feedbacks. What works well, what does not work.
Please don't use this post as a whishlist.
Attachments
MultiWii_dev_2014_12_01__r1729.torrent
(13.64 KiB) Downloaded 694 times

Curtisbeef
Posts: 1
Joined: Tue Dec 02, 2014 1:24 am

Re: pre 2.4 version r1729

Post by Curtisbeef »

I had my account deleted for my last post... Here is a way to say it without any offending anyone.

Posting code as a .torrent file is a extremely bad way to distribute code. Trackers go down.... People who don't use torrents have to download a client... old version being linked will confuse people... etc etc.

You should seriously consider uploading your code somewhere it can be maintained and contributions easily added. Consider trying out Github.
You can learn Github in about 15 min here: https://try.github.io

Curtis

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: pre 2.4 version r1729

Post by copterrichie »

There is also GDrive but it is clear, maybe it is time to consider Github or SourceForge http://sourceforge.net/

kalle123
Posts: 106
Joined: Sun Oct 09, 2011 10:07 am

Re: pre 2.4 version r1729

Post by kalle123 »

Good to see that there is still MultiWiiConf ...

br

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

Re: pre 2.4 version r1729

Post by Alexinparis »

@Curtisbeef
Yes I deleted your account with your first post.
You are not at home here, and your post (the only one you posted) was way too much aggressive for me. This one is soft enough to stay, even if off topic.
Maybe you don't know but the source code files are already hosted in google code.
https://code.google.com/p/multiwii/
You can still download here the file needed to test r1729
Howto: https://code.google.com/p/support/wiki/GettingStarted

I don’t expect to discuss in this post about the way to share files, nor your opinion on torrent.
I’m sure of nothing on this: take time to understand “I think it could… We will see if it's good enough or not.”

Use this post instead for further discussion on this topic
viewtopic.php?f=16&t=5853

The same for github, use this post instead:
viewtopic.php?f=8&t=825

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

Re: pre 2.4 version r1729

Post by Hamburger »

experimental:
heli yaw precomp dependant on collective pitch
individual cells voltage monitoring (alarm portion undone yet)

User avatar
Rudi48
Posts: 32
Joined: Mon Sep 19, 2011 10:44 am
Location: Wiesbaden, Germany
Contact:

Re: pre 2.4 version r1729

Post by Rudi48 »

Hello Alex,
Thank you very much for your excellent work :)

My setup is: QUADX, CRIUS_AIO_PRO_V1, GPS_SERIAL 2, UBLOX, VBAT, POWERMETER_HARD, PSENSOR_SMOOTH 64, Bluetooth

Just a feed back to a first test of the software:
GPS:
It would be nice to write in http://www.multiwii.com/wiki/index.php? ... lightmodes:
1. that GPS Hold works only, if there are more than 5 satellites seen, and ARM must be ON:
MultiWii.cpp 1133 if (GPS_numSat >5 ) {

2. that starting Return To Home, will immediately lift the copter to 15 m above start point.
If you do not know that in advance, you will be REALLY surprised.
config.h 751 #define RTH_ALTITUDE 15

3. A few words to MISSION and LAND would be helpful.

Power:
If you compile with POWERMETER_HARD, you get an error: 'powerValueMaxMAH' was not declared in this scope
For me, the solution is:
Arduino: 1.0.6 (Mac OS X), Board: "Arduino Mega 2560 or Mega ADK"
MultiWii.cpp: In function 'void annexCode()':
516 #ifdef POWERMETER_HARD -> #if defined(POWERMETER_HARD) && defined(LOG_VALUES)

In MultiWiiConf: Power: Total (see attached screenshot):
The unit here is: mA
I think it should be: mAh

The update frequency is very high for me to read, with PSENSOR_SMOOTH 16 = 48 ms (20 Hz).
I changed it to PSENSOR_SMOOTH 64 = 192 ms (5 Hz).

Best regards, Rudolf
Hobbyking EPP frame 455mm
Hobbyking EPP frame 455mm
Attachments
MultiWiiConf V231 with GPS and Power sensors
MultiWiiConf V231 with GPS and Power sensors

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

Re: pre 2.4 version r1729

Post by stronnag »

The decision to not to return an error status for MSP_PRIVATE unfortunately breaks third party tools (mwp, ez-gui) that attempt to distinguish e.g. cleanflight from mw by receipt of an error code (so now we have to add complexity to timeout code).

Please consider providing the error status according to the protocol (and extant wiki documentation) until mw implements MSP_PRIVATE.

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

Re: pre 2.4 version r1729

Post by Hamburger »

Hi Rudolf,
I am especially interested in that error with POWERMETER_HARD. Can you please attach your (maybe zipped) config.h so I can understand how that could happen. It has not come up with my any of my test configurations, so it might become interesting.

herzjung
Posts: 11
Joined: Sun Mar 06, 2011 8:53 pm

Re: pre 2.4 version r1729

Post by herzjung »

If I try to use the EOSBandi GUI it gives the failure notice "flight control sw Version mismatch, expected 23 got 231". How can I get the EOSBandi Gui functionality?

Best regards
Peter

TheBum
Posts: 35
Joined: Wed Dec 03, 2014 9:53 pm

Re: pre 2.4 version r1729

Post by TheBum »

Is there any reason the serialCom() invocation code in the SPEKTRUM version of readSerial_RX() couldn't also be used in the SUMD version of that function? I'll try to give it a test this evening.
Last edited by TheBum on Wed Dec 03, 2014 10:34 pm, edited 1 time in total.

herzjung
Posts: 11
Joined: Sun Mar 06, 2011 8:53 pm

Re: pre 2.4 version r1729

Post by herzjung »

I changed the version in the multiwii.h to 230 - now it works.

User avatar
Rudi48
Posts: 32
Joined: Mon Sep 19, 2011 10:44 am
Location: Wiesbaden, Germany
Contact:

Re: pre 2.4 version r1729

Post by Rudi48 »

Hello Hamburger,

In MultiWii.h is defined:
92 #if defined(LOG_VALUES) || defined(LCD_TELEMETRY) //
extern uint16_t cycleTimeMax; // highest ever cycle timen
extern uint16_t cycleTimeMin; // lowest ever cycle timen
extern int32_t BAROaltMax; // maximum value
extern uint16_t GPS_speedMax; // maximum speed from gps
extern uint16_t powerValueMaxMAH;
extern uint16_t wattsMax;
#endif

If neither LOG_VALUES nor LCD_TELEMETRY is defined, then powerValueMaxAH is NOT defined.

In MultiWii.cpp
516 #ifdef POWERMETER_HARD
if (analog.amperage > powerValueMaxMAH) powerValueMaxMAH = analog.amperage;
#endif

Hence, if POWERMETER_HARD is defined, then variable powerValueMaxMAH must be defined.
I have neither LOG_VALUES nor LCD_TELEMETRY defined.
So comes the error.

My patch is:
MultiWii.cpp:
516 #if defined(POWERMETER_HARD) && defined(LOG_VALUES)

Have I explained it well enough, to be understood?

Regards, Rudolf

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

Re: pre 2.4 version r1729

Post by Hamburger »

got it. Noted, thank you

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

Re: pre 2.4 version r1729

Post by stronnag »

Can we please have some means of disabling the intrusive "no fix" beeper as:

* It renders the useful beep functions useless;
* Some of us also fly in manual modes on GPS equipped vehicles.

This, along with the MSP_PRIVATE bug makes this version a regression compared to mw-nav b7.

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

Re: pre 2.4 version r1729

Post by stronnag »

stronnag wrote:Can we please have some means of disabling the intrusive "no fix" beeper as:

* It renders the useful beep functions useless;
* Some of us also fly in manual modes on GPS equipped vehicles.

This, along with the MSP_PRIVATE bug makes this version a regression compared to mw-nav b7.


The bug is in Alarm.h, line 79 where erroneously, ALRM_LVL_GPS_NOFIX = 1.

From MWNAV-b7, the correct assignment is

Code: Select all

ALRM_LVL_GPS_NOFIX  = 2


Please fix (and is there a bug tracker somewhere, rather than the forum)?

szakacs
Posts: 18
Joined: Wed Dec 11, 2013 11:53 pm
Location: Sydney, NSW Australia

Re: pre 2.4 version r1729

Post by szakacs »

herzjung wrote:I changed the version in the multiwii.h to 230 - now it works.


I tried this and I get the following.....Any ideas ??

************** 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:/Program%20Files/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:/Program%20Files/WinGUI_2.3pre10(b7)/GMap.NET.Core.DLL
----------------------------------------
GMap.NET.WindowsForms
Assembly Version: 1.7.0.0
Win32 Version: 1.7
CodeBase: file:///C:/Program%20Files/WinGUI_2.3pre10(b7)/GMap.NET.WindowsForms.DLL
----------------------------------------
ZedGraph
Assembly Version: 5.1.2.878
Win32 Version: 5.1.2.878
CodeBase: file:///C:/Program%20Files/WinGUI_2.3pre10(b7)/ZedGraph.DLL
----------------------------------------
AForge.Controls
Assembly Version: 2.2.3.0
Win32 Version: 2.2.3.0
CodeBase: file:///C:/Program%20Files/WinGUI_2.3pre10(b7)/AForge.Controls.DLL
----------------------------------------
AForge.Video
Assembly Version: 2.2.3.0
Win32 Version: 2.2.3.0
CodeBase: file:///C:/Program%20Files/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/Garry/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:/Program%20Files/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
----------------------------------------

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

Re: pre 2.4 version r1729

Post by stronnag »

Just flown three missions on r1729 (+Alarm.h patch). Tested the following (mwp as the planner):
  • Upload Mission
  • Dowload Mission
  • Fly mission with
    • Normal waypoints
    • Pos Hold Timed
    • Pos Hold Unlimited
  • Switched Pos Hold
  • Switched RTH
In a very gusty NW wind of 15knots gusting to 30+. Interesting to say the least. r1729 flys just fine, as shown the attachment. The pos hold circles (#5 and the RTH pos) slightly larger than some previous mwnav-b7 missions, but then it wan't blowing perhaps 25 knots for the previous missions, so I'm pretty confident with this build. And the 3DR radio was having a bad day, to say the least.

No noticeable difference in manual modes to the mw-nav builds.
r1729 test mission
r1729 test mission

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

Re: pre 2.4 version r1729

Post by Leo »

Please don't forget to include PPM for the Crius AIO Pro V2.x : http://www.multiwii.com/forum/viewtopic.php?f=8&t=4788

I'm using it with my Graupner HOTT setup.

herzjung
Posts: 11
Joined: Sun Mar 06, 2011 8:53 pm

Re: pre 2.4 version r1729

Post by herzjung »

Hi szakacs ,

My first lines in the multiwii.h are these:

#ifndef MULTIWII_H_
#define MULTIWII_H_

#define VERSION 230
//changed from 231

it dindn't make any difference in compiling and uploading but the EOS Bandi GUI works fine since then. I didn't find any difference to the NAV B7 so far.

Best regards
Peter

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

Re: pre 2.4 version r1729

Post by PatrikE »

When i have tested the NAV B7 code earlier i have got strange errors in Eos Wingui.
I discovered that it "crashes" if you don't uncomment
#define USE_MSP_WP
It seems it cant run without it!..

szakacs
Posts: 18
Joined: Wed Dec 11, 2013 11:53 pm
Location: Sydney, NSW Australia

Re: pre 2.4 version r1729

Post by szakacs »

PatrikE wrote:When i have tested the NAV B7 code earlier i have got strange errors in Eos Wingui.
I discovered that it "crashes" if you don't uncomment
#define USE_MSP_WP
It seems it cant run without it!..



That was it....Thanks so much...Now I can get back to testing :D

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

Re: pre 2.4 version r1729

Post by ezio »

PatrikE wrote:When i have tested the NAV B7 code earlier i have got strange errors in Eos Wingui.
I discovered that it "crashes" if you don't uncomment
#define USE_MSP_WP
It seems it cant run without it!..


USE_MSP_WP enables waypoints navigation

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

Re: pre 2.4 version r1729

Post by PatrikE »

ezio wrote:
PatrikE wrote:When i have tested the NAV B7 code earlier i have got strange errors in Eos Wingui.
I discovered that it "crashes" if you don't uncomment
#define USE_MSP_WP
It seems it cant run without it!..


USE_MSP_WP enables waypoints navigation

I know but the gui can not run at all without it.

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

Re: pre 2.4 version r1729

Post by Leo »

Leo wrote:Please don't forget to include PPM for the Crius AIO Pro V2.x : http://www.multiwii.com/forum/viewtopic.php?f=8&t=4788

I'm using it with my Graupner HOTT setup.


I'm retracting my request however maybe you could change the #define CRIUS_AIO_PRO_V1 to #define CRIUS_AIO_PRO_V1_V2 or just #define CRIUS_AIO_PRO
It would make life a bit easier.

TheBum
Posts: 35
Joined: Wed Dec 03, 2014 9:53 pm

Re: pre 2.4 version r1729

Post by TheBum »

TheBum wrote:Is there any reason the serialCom() invocation code in the SPEKTRUM version of readSerial_RX() couldn't also be used in the SUMD version of that function? I'll try to give it a test this evening.

It worked...sorta. The update rate in the GUI is really low, so it's far from an ideal solution. I should have an OLED showing up today and I'll probably just configure using stick commands.

User avatar
Rudi48
Posts: 32
Joined: Mon Sep 19, 2011 10:44 am
Location: Wiesbaden, Germany
Contact:

Re: pre 2.4 version r1729

Post by Rudi48 »

PatrikE wrote:When i have tested the NAV B7 code earlier i have got strange errors in Eos Wingui.
I discovered that it "crashes" if you don't uncomment
#define USE_MSP_WP
It seems it cant run without it!..

Thank you PatrikE,

You saved my day. Now WinGUI B7 works with MultiWii pre 2.4 r1729.
I could plan my first mission :D
I just have to change in MultiWii.h:
004 #define VERSION 230 // was 231 -> Problem with EZ-GUI

Also Android EZ-GUI does work now.

Regard, Rudolf

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

Re: pre 2.4 version r1729

Post by Hamburger »

Yes. In general applications/programs should consider being less restrictive on the version.
We increment the minor digit at will during development to indicate work in progress.
And most changes should not break existing functionality so users should be safe.

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

Re: pre 2.4 version r1729

Post by ezio »

Rudi48 wrote:
PatrikE wrote:When i have tested the NAV B7 code earlier i have got strange errors in Eos Wingui.
I discovered that it "crashes" if you don't uncomment
#define USE_MSP_WP
It seems it cant run without it!..

Thank you PatrikE,

You saved my day. Now WinGUI B7 works with MultiWii pre 2.4 r1729.
I could plan my first mission :D
I just have to change in MultiWii.h:
004 #define VERSION 230 // was 231 -> Problem with EZ-GUI

Also Android EZ-GUI does work now.

Regard, Rudolf


I have no idea why the EZ-GUI doesn't work for you. The communication protocol is the same. Just set in the settings the protocol to 2.3 Navigation and that's all. Even automatic detection should work.

Bart

ldonnay
Posts: 10
Joined: Wed Dec 24, 2014 12:00 pm

pre 2.4 version r1729

Post by ldonnay »

I am using a Futaba T8FG TX with a Frsky TFR4-SB RX. Thanks for all the fixes SBUS is now working without the need to change all the channels on the TX.
But I am still not able to use channels 9 to 14 any clue?

It also seems HEADFREE and HEADADJUST have been disabled?
Last edited by ldonnay on Wed Dec 24, 2014 12:21 pm, edited 1 time in total.

ldonnay
Posts: 10
Joined: Wed Dec 24, 2014 12:00 pm

pre 2.4 version r1729

Post by ldonnay »

Just activated HEADFREE in config.h
So just channels 9-14 to get to work.

Arakon
Posts: 196
Joined: Thu Jul 17, 2014 2:22 pm

Re: pre 2.4 version r1729

Post by Arakon »

Multiwii doesn't support more than 8 channels.

ldonnay
Posts: 10
Joined: Wed Dec 24, 2014 12:00 pm

pre 2.4 version r1729

Post by ldonnay »

If I follow this thread:
viewtopic.php?f=7&t=1701
it seems AUX5 and beyond can be used.

ldonnay
Posts: 10
Joined: Wed Dec 24, 2014 12:00 pm

pre 2.4 version r1729

Post by ldonnay »

First flight to tune gyro PIDs. Values are lower than with 2.3. P drops from 4.6 to 3.6 and I from 0,026 to 0,017 for both pitch and roll on F330 with 1200kv propdrive motors.

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

Re: pre 2.4 version r1729

Post by ezio »

Navigation Compatibility flag is set even when MSP_WP is disabled in config.h which doesn't make sense.
Please fix it.

ldonnay
Posts: 10
Joined: Wed Dec 24, 2014 12:00 pm

Re: pre 2.4 version r1729

Post by ldonnay »

ldonnay wrote:If I follow this thread:
viewtopic.php?f=7&t=1701
it seems AUX5 and beyond can be used.


Is the PID from TX POT feature included (in thread above Alex mentionned it was packaged)? I was able to add in the code but coundn't test it (as channels >8 are not active with Futaba T8FG SBUS for me).

There were also some attempts this summer to build and autotune version like the one in Cleanflight viewtopic.php?f=8&t=5190

Is this feature also in this version? I have not seen the source code in the r1729.

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

Re: pre 2.4 version r1729

Post by Alexinparis »

Hi,

@Rudi48:
It would be nice to write in http://www.multiwii.com/wiki/index.php? ... lightmodes:
1. that GPS Hold works only, if there are more than 5 satellites seen, and ARM must be ON:
MultiWii.cpp 1133 if (GPS_numSat >5 ) {

it's added for clarification

2. that starting Return To Home, will immediately lift the copter to 15 m above start point.
If you do not know that in advance, you will be REALLY surprised.
config.h 751 #define RTH_ALTITUDE 15

3. A few words to MISSION and LAND would be helpful.

I will add in the description the main post of EOS.
viewtopic.php?f=8&t=3989
where all the constraints you mentioned are described

In MultiWiiConf: Power: Total (see attached screenshot):
The unit here is: mA
I think it should be: mAh

ok, i also think so, corrected.

@ stronnag:
The decision to not to return an error status for MSP_PRIVATE unfortunately breaks third party tools (mwp, ez-gui) that attempt to distinguish e.g. cleanflight from mw by receipt of an error code (so now we have to add complexity to timeout code).

ok, I've commented the whole MSP_PRIVATE code part, which will give the same result

Can we please have some means of disabling the intrusive "no fix" beeper as:
...

ok, I think it is corrected now

@herzjung:
If I try to use the EOSBandi GUI it gives the failure notice "flight control sw Version mismatch, expected 23 got 231". How can I get the EOSBandi Gui functionality?

I switch back for the moment version number to 230, but winGUI will have to handle 240 for final 2.4

@ezio
Navigation Compatibility flag is set even when MSP_WP is disabled in config.h which doesn't make sense.

yes, obviously it was a wrongly tied to GPS_SERIAL, corrected now

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

Re: pre 2.4 version r1729

Post by Leo »

Think about changing the #define CRIUS_AIO_PRO_V1 to #define CRIUS_AIO_PRO_V1_V2 or better just #define CRIUS_AIO_PRO

It would save many newbies with the Cruis contoller having to ask what to set up.

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

Re: pre 2.4 version r1729

Post by Hamburger »

switch back for the moment version number to 230, but winGUI will have to handle 240 for final 2.4

I think it is wrong signal if we effectively cripple the version number only to please some (albeit honored) 3rd party app.
If they test for ==230 then it is either intended or plain wrong and bad.

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

pre 2.4 version r1729

Post by ezio »

Hamburger wrote:
switch back for the moment version number to 230, but winGUI will have to handle 240 for final 2.4

I think it is wrong signal if we effectively cripple the version number only to please some (albeit honored) 3rd party app.
If they test for ==230 then it is either intended or plain wrong and bad.

+1

Sent from my Nexus 5 using Forum Fiend v1.2.14.

User avatar
Rudi48
Posts: 32
Joined: Mon Sep 19, 2011 10:44 am
Location: Wiesbaden, Germany
Contact:

Re: pre 2.4 version r1729

Post by Rudi48 »

Hamburger wrote:
switch back for the moment version number to 230, but winGUI will have to handle 240 for final 2.4

I think it is wrong signal if we effectively cripple the version number only to please some (albeit honored) 3rd party app.
If they test for ==230 then it is either intended or plain wrong and bad.

Hello Alex,

I think that version number 231 is OK for now.
WinGUI and EZ-GUI should test for >=230.

If you use WinGUI, you could easily edit the version number from 231 to 230 (in MultiWii.h) without problem, what I did.
Program EZ-GUI has the same problem.
The actual Program MultiWiiConf can still be used after that change.

Regards, Rudolf

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

Re: pre 2.4 version r1729

Post by Alexinparis »

About the version, ok, I understand the concern. so switch back to 231.
At the beginning, I introduced the version variable with only with 2 digits.
multiwii 2.0 : version = 20
If I remember well, Hamburger modified the convention in multiwii 2.1: version = 210
The purpose behind: increment VERSION to reflect work in progress. but it was not the original purpose ;)
For me a dev version is a kind of draft with no "release version"
With this convention, the version is limited to 2.5 and I don't want really to introduce a new var just to push version up.
So, I think the 2.4 will still have the number 240, and we will see after.

carlonb
Posts: 210
Joined: Sun Apr 03, 2011 6:29 pm

Re: pre 2.4 version r1729

Post by carlonb »

Hi Alex,
Can you please provide to reset the baro altitude when arming ?
So we can reset the altitude at every take off avoiding to disconnect the battery for resetting it.
Thanks in advance
Carlo

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

Re: pre 2.4 version r1729

Post by Hamburger »

Carlo,
But then you cannot land at other place (mountain) to deliver package (there disarm and arm) because on flight back the altitude will be corrupt= different from first direction.
Not a good idea.
If you have a Bt connection to your fc, then you can send a 'R' for resetting various values.
This is already possible with a terminal program and maybe with ezgui?
Last edited by Hamburger on Wed Dec 31, 2014 4:19 am, edited 1 time in total.

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

Re: pre 2.4 version r1729

Post by Hamburger »

Alex,
I think with your last change to gui you also reactivated the truncation of leading /dev etc. from serial device names?
If true then it breaks the rwconnect feature for mac and * nix. I had had to disable this truncations long ago for that reason although it was nicer reading the list.
Sorry I am not 100% sure about your change as I cannot read code easily right now - travellin

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

Re: pre 2.4 version r1729

Post by Leo »

Hamburger wrote:Carlo,
But then you cannot land at other place (mountain) to deliver package (there disarm and arm) because on flight back the altitude will be corrupt= different from first direction.
Not a good idea.
If you have a Bt connection to your fc, then you can send a 'R' for resetting various values.
This is already possible with a terminal program and maybe with ezgui?


Thanks for the explanation. However the fact that the baro isn't reset is bugging me also.
E.g. yesterday I turned on the Quad at a higher level to do some tests. Then I took it to a lower position to do some flights. It was disarmed but the Lipo still plugged in. When I reviewed my flight on Google Earth many portions of the flight path where below ground. Not nice...

Here 2 ideas:

1. Give the user the option in the conf file e.g.: #define disarm_reset_baro

2. Assign the reset to baro hold function. If the Quad is on the ground in a disarmed state the user can flip the baro hold switch to initiate baro reset. This would be my preference.

What do you guys think?

Leo

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

Re: pre 2.4 version r1729

Post by Hamburger »

Of the two I.d prefer the second variant. But I have no grasp of possible side effects as my experience with gps and baro are limited. So it may have to wait until after 2.4 or other frequent users of such combos must chime in.

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

Re: pre 2.4 version r1729

Post by PatrikE »

I always calibrate Gyros before takeoff.
This also reset Baro Altitude.

Code: Select all

       if (rcSticks == THR_LO + YAW_LO + PIT_LO + ROL_CE) {    // GYRO calibration
          calibratingG=512;
          #if GPS
            GPS_reset_home_position();
          #endif
          #if BARO
            calibratingB=10;  // calibrate baro to new ground level (10 * 25 ms = ~250 ms non blocking)
          #endif
        }

Just do the stick commands for Gyro calib...
THR_LO + YAW_LO + PITCH_LO + ROLL_CENTER

And it's been in the code for ages..

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

Re: pre 2.4 version r1729

Post by Alexinparis »

PatrikE wrote:I always calibrate Gyros before takeoff.
This also reset Baro Altitude.

Code: Select all

       if (rcSticks == THR_LO + YAW_LO + PIT_LO + ROL_CE) {    // GYRO calibration
          calibratingG=512;
          #if GPS
            GPS_reset_home_position();
          #endif
          #if BARO
            calibratingB=10;  // calibrate baro to new ground level (10 * 25 ms = ~250 ms non blocking)
          #endif
        }

Just do the stick commands for Gyro calib...
THR_LO + YAW_LO + PITCH_LO + ROLL_CENTER

And it's been in the code for ages..


Yes, this is exactly what i was going to respond.
I've just added a small note in the wiki: http://www.multiwii.com/wiki/index.php? ... figuration

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

Re: pre 2.4 version r1729

Post by Alexinparis »

Hamburger wrote:Alex,
I think with your last change to gui you also reactivated the truncation of leading /dev etc. from serial device names?
If true then it breaks the rwconnect feature for mac and * nix. I had had to disable this truncations long ago for that reason although it was nicer reading the list.
Sorry I am not 100% sure about your change as I cannot read code easily right now - travellin


Ok, I didn't remember this issue
viewtopic.php?f=8&t=4077&p=41692#p41692
so switch back to the previous code. maybe something to correct for the next one.

Post Reply