MultiWii

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

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.

Nunchuk is no more suported

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

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 motors option on 32u4 proc at 8/16/32 kHz

brushed motors option on 328p proc at 1/4/32 kHz
(viewtopic.php?f=8&t=3635&p=36883#p36877)

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

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

experimental : piro compensation

experimental : better tail lock tacking intoo account collective pitch

compute watts

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.

ALRM_LVL_GPS_NOFIX  = 2

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

• Upload Mission
• Dowload Mission
• Fly mission with
  
  • Normal waypoints
  • Pos Hold Timed
  • Pos Hold Unlimited
• Switched Pos Hold
• Switched RTH

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

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

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

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.

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.

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

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

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

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.

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

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

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

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?

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

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

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.

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.

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?

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

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