2.4 is finally here :)

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download

2.4 is finally here :)

Postby Alexinparis » Sun Mar 15, 2015 11:42 pm

http://code.google.com/p/multiwii/

After a very very long time, this version is finally released :)
A big thank for all contributions

main changes 2.3 -> 2.4

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?viewtopic.php?f=8&t=3989

For the moment, only some GUIs can support this code to program a mission:
- WinGui from EOSBandi (http://eosbandi.com/downloads )
- EZ-GUI from Ezio (in google play apps https://play.google.com/store/apps/deta ... o.multiwii)
- mwp mission planner from stronnag (https://github.com/stronnag/mwptools)

tmp note for WinGui:
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
will be soon supported with a new WinGui release

No support in java GUI MultiWiiConf.

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.

internal code modification:
- 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
- brushed motors option on 328p proc at 1/4/32 kHz
viewtopic.php?viewtopic.php?f=8&t=3635&p=36883#p36877


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

- new MSP message for ACC TRIM (not used in java MultiWiiConf)
- new MSP message for cells voltage
- new MSP messages for GPS navigation
- remove MSP ack for MSP_SET_RAW_RC, and only for this message


Sonar

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


Heli

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


LCD

- LCD.lcd03 over serial support added



reference version to compile sketch

- MultiWii sketch : windows version of Arduino IDE 1.6.1
- MultiWiiConf : processing 1.5.1 with modified verison of ControlP5 to remove blue triangles in value box
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: 2.4 is finally here :)

Postby haydent » Mon Mar 16, 2015 3:03 am

thanks for your continued work all !
User avatar
haydent
 
Posts: 583
Joined: Sun Jun 17, 2012 1:35 am
Location: NSW, AU

Re: 2.4 is finally here :)

Postby howardhb » Mon Mar 16, 2015 6:49 am

+1
Many thanks!
An epic journey, to be sure :mrgreen:
User avatar
howardhb
 
Posts: 189
Joined: Tue Oct 11, 2011 7:10 pm
Location: Port Elizabeth, South Africa

Re: 2.4 is finally here :)

Postby Leo » Mon Mar 16, 2015 7:00 am

Fantastic!

Thanks to all involved in making this release possible :)

Now we have a good base to add and test new features...
User avatar
Leo
 
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany

Re: 2.4 is finally here :)

Postby stronnag » Mon Mar 16, 2015 9:01 am

Congratulations.

Flew it yesterday. Performed as expected.
User avatar
stronnag
 
Posts: 114
Joined: Thu Oct 24, 2013 9:32 pm
Location: New Forest, England

Re: 2.4 is finally here :)

Postby PatrikE » Mon Mar 16, 2015 10:45 am

@stonemag,

Can you provide compiled Gui's for non developers?
Not everyone have a compiler installed or the knowledge howto..

Win,Mac & Linux for most users.
PatrikE
 
Posts: 1925
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden

Re: 2.4 is finally here :)

Postby kalle123 » Mon Mar 16, 2015 12:37 pm

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

Re: 2.4 is finally here :)

Postby joelmeijering » Mon Mar 16, 2015 3:06 pm

It's like you read my mind and added precisely the features I wanted! I love the RSSI possibility.
joelmeijering
 
Posts: 4
Joined: Sun Jan 11, 2015 2:15 pm

Re: 2.4 is finally here :)

Postby willow609 » Mon Mar 16, 2015 4:16 pm

Hi all. Will this work with a crius aiopro v2 board. Many thanks.
willow609
 
Posts: 3
Joined: Sun Mar 15, 2015 4:59 pm

Re: 2.4 is finally here :)

Postby TheBum » Mon Mar 16, 2015 4:20 pm

Alexinparis wrote:reference version to compile sketch

- MultiWii sketch : windows version of Arduino IDE 1.6.1
- MultiWiiConf : processing 1.5.1 with modified verison of ControlP5 to remove blue triangles in value box

Is the Mac version of Arduino 1.6.1 excluded because it's broken? I upgraded to 1.6.1 and had to go back to 1.6.0 because 1.6.1 was spewing error messages when attempting to build from my svn sandbox. I haven't updated my sandbox with 2.4 final yet.
TheBum
 
Posts: 35
Joined: Wed Dec 03, 2014 9:53 pm

Re: 2.4 is finally here :)

Postby Leo » Mon Mar 16, 2015 4:34 pm

willow609 wrote:Hi all. Will this work with a crius aiopro v2 board. Many thanks.


It will work great with this board! :)
User avatar
Leo
 
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany

Re: 2.4 is finally here :)

Postby willow609 » Mon Mar 16, 2015 6:59 pm

Excellent that's great news cheers.
willow609
 
Posts: 3
Joined: Sun Mar 15, 2015 4:59 pm

Re: 2.4 is finally here :)

Postby zed_thirteen » Mon Mar 16, 2015 7:18 pm

great news, thanks guys
zed_thirteen
 
Posts: 3
Joined: Sun Nov 02, 2014 2:32 pm

Re: 2.4 is finally here :)

Postby zed_thirteen » Mon Mar 16, 2015 8:41 pm

Are the stored parameters compatible with 2.3 or do I need to erase the EPROM space?
zed_thirteen
 
Posts: 3
Joined: Sun Nov 02, 2014 2:32 pm

Re: 2.4 is finally here :)

Postby TheBum » Tue Mar 17, 2015 2:04 am

TheBum wrote:
Alexinparis wrote:reference version to compile sketch

- MultiWii sketch : windows version of Arduino IDE 1.6.1
- MultiWiiConf : processing 1.5.1 with modified verison of ControlP5 to remove blue triangles in value box

Is the Mac version of Arduino 1.6.1 excluded because it's broken? I upgraded to 1.6.1 and had to go back to 1.6.0 because 1.6.1 was spewing error messages when attempting to build from my svn sandbox. I haven't updated my sandbox with 2.4 final yet.

Nevermind. I wrongly assumed that my board and serial port settings would be retained with the Arduino update. I did notice that the compilation with 1.6.1 is considerably smaller than with 1.6.0.
TheBum
 
Posts: 35
Joined: Wed Dec 03, 2014 9:53 pm

Re: 2.4 is finally here :)

Postby Hamburger » Tue Mar 17, 2015 7:07 pm

zed_thirteen wrote:Are the stored parameters compatible with 2.3 or do I need to erase the EPROM space?

for almost all configs you want to erase first.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: 2.4 is finally here :)

Postby Lecostarius » Thu Mar 19, 2015 11:52 pm

Hi all,

thank you for the great work! --

By the way, where should any bug reports for 2.4 go?

Incidentally, I have a bug report ;-). Inflight calibration with the CALIB switch does not work as designed. The fix is as follows:

lines 1016..1018 of MultiWii.cpp currently look like this (in 2.4, but the bug is present in 2.3 as well):
Code: Select all
        if (!AccInflightCalibrationActive && !AccInflightCalibrationMeasurementDone){
          InflightcalibratingA = 50;
        }

and should look like that:
Code: Select all
        if (!AccInflightCalibrationActive && !AccInflightCalibrationMeasurementDone){
          InflightcalibratingA = 50; AccInflightCalibrationActive = 1;
        }

Without setting AccInflightCalibrationActive, the calibration will be continuously restarted while the CALIB switch is active. After landing and disarming, and releasing the switch, the actual measurement will take place and the accelerometer values (of the copter that is standing on the ground) will be taken as reference. This is definitely not what inflight calibration should do.

Cheers, Leco
Lecostarius
 
Posts: 46
Joined: Mon Oct 20, 2014 11:29 pm

Re: 2.4 is finally here :)

Postby Leo » Fri Mar 20, 2015 9:18 am

Well, I've done 5 navigation flights with the new version in the last two days. All seems to be working.

Side note:
However I've picked a bad time to do these tests as on every flight something would go haywire. Right now we have very strong geomagnetic interference and heavy solar activity. I usually get 10 sat's locked but sometimes the number of sat's came down to 5 during flight which made navigation go crazy.
As I write this we will have a solar eclipse in Europe in an hour or so. Maybe the phenomena is causing the erratic behavior during the flights :?:
User avatar
Leo
 
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany

Re: 2.4 is finally here :)

Postby QuadBow » Sat Mar 21, 2015 11:20 pm

I know, the 2.4pre discussion has been closed and the 2.4 has been released.
However, I found an issue with the following line of code just today:
Code: Select all
analog.amperage = ((uint32_t)powerValue * conf.pint2ma) / 100; // [100mA] //old (will overflow for 65A: powerValue * conf.pint2ma; // [1mA]

So the amperage resolution has been reduced by the factor 100 and the range has been extended by the same factor.
That means for my small copter a very poor accuracy in particular at low load.
The variables will overflow at 6500A - that's good news for big copters!

But, is this really what we want? Is there really someone requiring 6500A?
I thing a good compromise would be the following code, which should be acceptable for smaller and bigger copters:
Code: Select all
analog.amperage = ((uint32_t)powerValue * conf.pint2ma) / 10; // [10mA]
QuadBow
 
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: 2.4 is finally here :)

Postby Hamburger » Sun Mar 22, 2015 8:59 pm

Do you really see accurate measurements with 10mA steps from your sensor all the way through the adc?
Me I feel lucky if the value is accurate at the 1A digit.

Which sensor and RC.filter do you use please?
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: 2.4 is finally here :)

Postby QuadBow » Mon Mar 23, 2015 7:36 pm

Hi Hamburger,

Hamburger wrote:Do you really see accurate measurements with 10mA steps from your sensor all the way through the adc?
Of course, I don't.
With a PINT2mA of roughly 100 you will always have a difference of 100=0.1A even when filtering.

I got a PINT2mA of 74 resulting to a 0.444 A or 0.518 A when armed. The display flips between both values.
When dividing by 100 - as done in MW 2.4 - the result is: The display swaps between the values 0.400 A and 0.500 A. So what is the benefit of doing so?

My proposal as a compromise was to chose a basis of 10mA (instead of 1mA in MW 2.3 or 100mA in MW 2.4). That would allow a better accuracy and a good range up to 650A. The values will flip (between 0.44 A and 0.51 A), but as I have explained they will do in any case.
QuadBow
 
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: 2.4 is finally here :)

Postby Hamburger » Mon Mar 23, 2015 10:20 pm

with your current sensor and a given current, how stable is the value you see for analogRead()? How many bits is noise?
I am not convinced it is a good idea to display digits which carry useless random values. I left the first decimal only to show trend and existing fluctuation.
For the pure information I would only display amps as integer value without any decimals.

I welcome your giving this some thought. As far as I can tell without looking at the code, changes may impact the gui (over msp) and the lcd:telemetry stuff.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: 2.4 is finally here :)

Postby QuadBow » Tue Mar 24, 2015 7:04 am

Hi Hamburger,
Thank you for the elaboration. I share your point that it is actually not worth to undertake the effort of changing the protocol for some more flickering decimals.
So, I can live with the current resolution of 100mA, since the more important variable pMeter[] has not been changed compared to MW 2.3.
I just was curious about the reasons for the change from mA to 100mA, which took place in MW 2.4.
My only plee for the current implementation would be to add a rounding like
Code: Select all
analog.amperage = (((uint32_t)powerValue * conf.pint2ma) + 50) / 100; // [100mA]    //old (will overflow for 65A: powerValue * conf.pint2ma; // [1mA]
QuadBow
 
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: 2.4 is finally here :)

Postby TheBum » Tue Mar 24, 2015 4:36 pm

I'll add my $0.02 to the amperage discussion. I chose to go with a 50A Hall effect sensor for my mini quad and the resolution works out to 61.25mA (80mV/A). I don't think you'll get much lower than that, and higher rated sensors will be even worse. Therefore, 100mA resolution on the display should be more than sufficient.
TheBum
 
Posts: 35
Joined: Wed Dec 03, 2014 9:53 pm

Re: 2.4 is finally here :)

Postby TheBum » Tue Mar 24, 2015 6:36 pm

There's a documentation typo in 2.4 that was there in 2.3 and, being the anal-retentive person I am, it's driving me nuts.

In MultiWii.cpp, the comment at the end of the following line is wrong:
Code: Select all
pMeter[PMOTOR_SUM] += ((currentTime-lastRead) * (uint32_t)((uint32_t)powerValue*conf.pint2ma))/100000; // [10 mA * msec]


It should be 100 mA * msec based on the equation. The unscaled units are mA * µsec. To get 10 mA * msec, you'd have to divide by 10 and 1000, i.e. 10000.
TheBum
 
Posts: 35
Joined: Wed Dec 03, 2014 9:53 pm

Re: 2.4 is finally here :)

Postby Hamburger » Tue Mar 24, 2015 9:22 pm

TheBum wrote:I'll add my $0.02 to the amperage discussion. I chose to go with a 50A Hall effect sensor for my mini quad and the resolution works out to 61.25mA (80mV/A). I don't think you'll get much lower than that, and higher rated sensors will be even worse. Therefore, 100mA resolution on the display should be more than sufficient.

thanks for the input. What is your experience with the accuracy of analogRead() in MWii on avr boards?
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: 2.4 is finally here :)

Postby Hamburger » Tue Mar 24, 2015 9:23 pm

TheBum wrote:There's a documentation typo in 2.4 that was there in 2.3 and, being the anal-retentive person I am, it's driving me nuts.

In MultiWii.cpp, the comment at the end of the following line is wrong:
Code: Select all
pMeter[PMOTOR_SUM] += ((currentTime-lastRead) * (uint32_t)((uint32_t)powerValue*conf.pint2ma))/100000; // [10 mA * msec]


It should be 100 mA * msec based on the equation. The unscaled units are mA * µsec. To get 10 mA * msec, you'd have to divide by 10 and 1000, i.e. 10000.

I do not think it would justify a recall of v2.4, but I will take a closer look for v2.5. Thanks.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: 2.4 is finally here :)

Postby Chappie » Wed Mar 25, 2015 2:48 am

I am getting longitude spikes with 8-10 satellites....I have a multiwii pro running 2.4 and navi b7...any thoughts? Switched from 2.3 with b5 and i did clear eeprom when updating to 2.4. Little bit of a newbie here. Thanks.

Steve
Chappie
 
Posts: 1
Joined: Wed Mar 25, 2015 12:34 am

Re: 2.4 is finally here :)

Postby TheBum » Wed Mar 25, 2015 3:10 am

Hamburger wrote:I do not think it would justify a recall of v2.4, but I will take a closer look for v2.5. Thanks.

I don't either, but it needed to be pointed out IMO.
TheBum
 
Posts: 35
Joined: Wed Dec 03, 2014 9:53 pm

Re: 2.4 is finally here :)

Postby jaysonragasa » Fri Mar 27, 2015 2:43 pm

I made a small changes in AlexK PID_CONTRORLLER based on cleanflight's "ReWrite"

Code: Select all
#define GYRO_I_MAX 256
#define ACC_I_MAX 256
   prop = min(max(abs(rcCommand[PITCH]), abs(rcCommand[ROLL])), 500); // range [0;500]
   
   //----------PID controller----------
   for (axis = 0; axis < 3; axis++) {
      //-----Get the desired angle rate depending on flight mode
      //if ((f.ANGLE_MODE || f.HORIZON_MODE) && axis < 2) { // MODE relying on ACC
      //   // calculate error and limit the angle to 50 degrees max inclination
      //   // errorAngle = constrain((rcCommand[axis] << 1) + GPS_angle[axis], -500, +500) - att.angle[axis] + conf.angleTrim[axis]; //16 bits is ok here
      //}

      if (axis == 2) {//YAW is always gyro-controlled (MAG correction is applied to rcCommand)
         AngleRateTmp = (((int32_t) (conf.yawRate + 27) * rcCommand[2]) >> 5);
      }
      else {
         // calculate error and limit the angle to 50 degrees max inclination
#if GPS
         //errorAngle = constrain((rcCommand[axis] << 1) + GPS_angle[axis], -500, +500) - att.angle[axis] + conf.angleTrim[axis]; //16 bits is ok here
         errorAngle = constrain(2 * rcCommand[axis] + GPS_angle[axis], -500, +500) - att.angle[axis] + conf.angleTrim[axis]; //16 bits is ok here
#else
         errorAngle = constrain(2 * rcCommand[axis], -500, +500) - att.angle[axis] + conf.angleTrim[axis]; //16 bits is ok here
#endif

         if (!f.ANGLE_MODE) {//control is GYRO based (ACRO and HORIZON - direct sticks control is applied to rate PID
            AngleRateTmp = ((int32_t) (conf.rollPitchRate + 27) * rcCommand[axis]) >> 4;
            if (f.HORIZON_MODE) {
               //mix up angle error to desired AngleRateTmp to add a little auto-level feel
               AngleRateTmp += ((int32_t) errorAngle * conf.pid[PIDLEVEL].I8) >> 8;
            }
         }
         else {//it's the ANGLE mode - control is angle based, so control loop is needed
            AngleRateTmp = ((int32_t) errorAngle * conf.pid[PIDLEVEL].P8) >> 4;
         }
      }

      //--------low-level gyro-based PID. ----------
      //Used in stand-alone mode for ACRO, controlled by higher level regulators in other modes
      //-----calculate scaled error.AngleRates
      //multiplication of rcCommand corresponds to changing the sticks scaling here
      RateError = AngleRateTmp - imu.gyroData[axis];

      //-----calculate P component
      PTerm = ((int32_t) RateError * conf.pid[axis].P8) >> 7;

      //-----calculate I component
      //there should be no division before accumulating the error to integrator, because the precision would be reduced.
      //Precision is critical, as I prevents from long-time drift. Thus, 32 bits integrator is used.
      //Time correction (to avoid different I scaling for different builds based on average cycle time)
      //is normalized to cycle time = 2048.
      errorGyroI[axis] += (((int32_t) RateError * cycleTime) >> 11) * conf.pid[axis].I8;
      //limit maximum integrator value to prevent WindUp - accumulating extreme values when system is saturated.
      //I coefficient (I8) moved before integration to make limiting independent from PID settings
      errorGyroI[axis] = constrain(errorGyroI[axis], (int32_t) -GYRO_I_MAX << 13, (int32_t) +GYRO_I_MAX << 13);
      ITerm = errorGyroI[axis] >> 13;

      //-----calculate D-term
      delta = RateError - lastError[axis];  // 16 bits is ok here, the dif between 2 consecutive gyro reads is limited to 800
      lastError[axis] = RateError;

      //Correct difference by cycle time. Cycle time is jittery (can be different 2 times), so calculated difference
      // would be scaled by different dt each time. Division by dT fixes that.
      delta = ((int32_t) delta * ((uint16_t) 0xFFFF / (cycleTime >> 4))) >> 6;
      //add moving average here to reduce noise
      deltaSum = delta1[axis] + delta2[axis] + delta;
      delta2[axis] = delta1[axis];
      delta1[axis] = delta;

      //DTerm = (deltaSum*conf.pid[axis].D8)>>8;
      //Solve overflow in calculation above...
      DTerm = ((int32_t) deltaSum * conf.pid[axis].D8) >> 8;
      //-----calculate total PID output
      axisPID[axis] = PTerm + ITerm + DTerm;
   }
User avatar
jaysonragasa
 
Posts: 53
Joined: Wed Jan 28, 2015 6:40 am
Location: Philippines

Re: 2.4 is finally here :)

Postby QuadBow » Fri Mar 27, 2015 5:34 pm

jaysonragasa wrote:I made a small changes in AlexK PID_CONTRORLLER based on cleanflight's "ReWrite"

And what is the benefit of this exercise?
QuadBow
 
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: 2.4 is finally here :)

Postby Maine_Guy » Fri Mar 27, 2015 6:19 pm

Looks great. I compiled it - but have not flown it yet. I've implemented this on an airplane, the flight characteristics are very nice.

If I were to make a small donation, where should I send it? (knowing this is a loaded question). Not sure how this message board is funded - or who exactly is doing all the work these days?

EDIT:
Never mind, found the donation link (it was documented after all). Going directly to this forum bypasses the main 'home' screen with donation info. Thanks for the efforts!
Maine_Guy
 
Posts: 27
Joined: Fri Mar 06, 2015 7:07 pm

Re: 2.4 is finally here :)

Postby RCvertt » Wed Apr 08, 2015 10:18 am

Good work on 2.4
Alexinparis wrote:- heading is computed even with no mag

What does this mean? We now have some heading hold using just a gyro and accel as an option? If so how do we activate this feature or is it on all the time?
RCvertt
 
Posts: 136
Joined: Fri Sep 14, 2012 11:45 am

Re: 2.4 is finally here :)

Postby TheBum » Wed Apr 08, 2015 11:12 pm

RCvertt wrote:Good work on 2.4
Alexinparis wrote:- heading is computed even with no mag

What does this mean? We now have some heading hold using just a gyro and accel as an option? If so how do we activate this feature or is it on all the time?

The only method I can think of without a mag sensor is GPS, and then only when the model is moving.
TheBum
 
Posts: 35
Joined: Wed Dec 03, 2014 9:53 pm

Re: 2.4 is finally here :)

Postby ttcorse » Thu Apr 09, 2015 8:30 pm

the ide does not compile if activate:
#define SERVO TILT
Shows the following error:









In file included from Output.cpp:3:0:
Output.cpp: In function 'void __vector_14()':
def.h:1431:38: error: 'PORTL' was not declared in this scope
#define SERVO_1_PIN_HIGH PORTL |= 1<<5;
^
def.h:683:24: note: in expansion of macro 'SERVO_1_PIN_HIGH'
#define SERVO_1_HIGH SERVO_1_PIN_HIGH
^
Output.cpp:908:7: note: in expansion of macro 'SERVO_1_HIGH'
SERVO_1_HIGH; // set servo 1's pin high
^
def.h:1432:38: error: 'PORTL' was not declared in this scope
#define SERVO_1_PIN_LOW PORTL &= ~(1<<5);
^
Output.cpp:897:7: note: in definition of macro 'SERVO_PULSE'
LAST_PIN_LOW; \
^
def.h:684:23: note: in expansion of macro 'SERVO_1_PIN_LOW'
#define SERVO_1_LOW SERVO_1_PIN_LOW
^
Output.cpp:915:50: note: in expansion of macro 'SERVO_1_LOW'
SERVO_PULSE(SERVO_2_HIGH,2,SERVO_2_ARR_POS,SERVO_1_LOW); // the same here
^
In file included from Output.cpp:3:0:
def.h:1435:38: error: 'PORTL' was not declared in this scope
#define SERVO_2_PIN_LOW PORTL &= ~(1<<4);
^
def.h:689:20: note: in expansion of macro 'SERVO_2_PIN_LOW'
#define LAST_LOW SERVO_2_PIN_LOW
^
Output.cpp:936:7: note: in expansion of macro 'LAST_LOW'
LAST_LOW;
^
Errore durante la compilazione
ttcorse
 
Posts: 17
Joined: Sun Feb 03, 2013 7:53 am

Re: 2.4 is finally here :)

Postby Noctaro » Sat Apr 11, 2015 11:01 am

Hi all,
i had some troubles the last few days with 2 multiwii pro boards with mtk gps.

It seems #init Mtkgps does not work in multiwii 2.4.
Until now i had no time to test the new release and give feedback. Sorry....

This is what happened:
I got a brandnew multiwii pro board from HK.
Of course i wanted to start with 2.4 rightaway.
As usual i uncomment all GPS settings that are needed:
#define FFIMUv2
#define SERIAL2_COM_SPEED 57600 //also tried standart baudrate
#define GPS_SERIAL 2
#define GPS_BAUD 57600
#define NMEA
#define INIT_MTK_GPS

The GPS module would not initialize... I tried my secound new board, same behaviour.
I redownloaded the multiwii sketch and reconfigured it a secound time to be sure i have messed nothing up.

I gave up on 2.4 and flashed 2.3.
Istant i got a working gps with the same configuration. So i commented //#define INIT_MTK_GPS in 2.4 and gave it another try.
Now i got instant satlock with 2.4, works as it should.

I will not find the bug in the code, if there is one.....you know my programming skills are like :?:
but maybe someone other does. :)

Thank you!

Greetz Noc

edit: Sorry, did not see there already was an topic -> viewtopic.php?f=18&t=6317
Noctaro
 
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am

Re: 2.4 is finally here :)

Postby RCvertt » Mon Apr 13, 2015 9:57 am

TheBum wrote:The only method I can think of without a mag sensor is GPS, and then only when the model is moving.
Sure about that? I've never heard of heading hold with GPS only. GPS is rather inaccurate so I can't imagine that being the case?

I've heard of gyros only heading hold. That's how all helicopter heading hold was done before and many still do it that way. Some integrate the accel now for a more accurate heading hold when a mag isn't used.
RCvertt
 
Posts: 136
Joined: Fri Sep 14, 2012 11:45 am

Re: 2.4 is finally here :)

Postby Hamburger » Mon Apr 13, 2015 1:52 pm

ttcorse wrote:the ide does not compile if activate:
#define SERVO TILT
Errore durante la compilazione

Please zip your config.h and post that here. Which version of IDE do you use?
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: 2.4 is finally here :)

Postby ttcorse » Wed Apr 15, 2015 6:46 am

config.rar
(20.14 KiB) Downloaded 212 times

my ide is arduino 1.6.1
Thanks
ttcorse
 
Posts: 17
Joined: Sun Feb 03, 2013 7:53 am

Re: 2.4 is finally here :)

Postby m.homayoun » Mon Apr 20, 2015 10:57 am

Hi All
sorry. I want to know if i want to use ublox gps with srf04 sonar Do I still have to use MWC I2C-GPS NAV module board with I2C_GPS_NAV code on multiwii 2.4??????
m.homayoun
 
Posts: 9
Joined: Mon Jul 28, 2014 10:28 am

Re: 2.4 is finally here :)

Postby QuadBow » Tue Apr 21, 2015 6:22 am

m.homayoun wrote:I want to know if i want to use ublox gps with srf04 sonar Do I still have to use MWC I2C-GPS NAV module board with I2C_GPS_NAV code on multiwii 2.4
No, you can't and you have to use the additional i2c_gps_nav module.
Under http://www.multiwii.com/forum/viewtopic.php?f=8&t=6282 it is being discussed how to integrate the SRF04 into multiwii 2.4. But, there seem to be many questions and issues. The best thingwould be to use an i2c based sonar module like the SRF08, which has already been integrated.
QuadBow
 
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: 2.4 is finally here :)

Postby Fredasss » Mon Apr 27, 2015 6:42 pm

Hi everybody,
I stuck in the same way with my MTK GPS.
I've just bought a HK multiwii pro, and updated it to 2.4,
I tried these settings:

#define SERIAL2_COM_SPEED 57600 //also tried standart baudrate
#define GPS_SERIAL 2
#define GPS_BAUD 57600
#define NMEA
#define INIT_MTK_GPS

tried to change baud rate, but nothing appened in the GUI.
can you please help me to find a way to make it work ?
thanks by advance.

Fred
Fredasss
 
Posts: 1
Joined: Mon Apr 27, 2015 6:38 pm

Re: 2.4 is finally here :)

Postby makattack » Mon Apr 27, 2015 6:45 pm

Just a curious observation since I've updated my Flip1.5 (RTFQuads) board installed on a tricopter.

The first thing I noticed when I plug the board into the computer and connected with MultiWiiConf is that the graphic representation for the tricopter shows it rotating clockwise until I recalibrate the gyros. Interestingly, when I but a battery in an fly it, it does the same clockwise yaw in rate mode, but I can compensate with steady stick yaw input (or trim probably, but I didn't try using TX trim). This is after powering it up on a steady/flat platform and waiting a good amount of time after the LED's indicate ready state before arming. If I land, and use stick commands to recalibrate the gyros, it removes the yaw drift when I take off again.

I'm using the released version of MW2.4 / MWC 2.4. I erased the eeprom before flashing the new version, and have in fact done so twice just for good measure.

I'm assuming this is related to the new implementation of the compass heading using the gyro/accelerometers INS input without a need for a magnetometer, but I'm flying in rate mode without any heading hold feature even enabled.

Has anyone else seen this?
makattack
 
Posts: 2
Joined: Mon Apr 13, 2015 11:28 pm

Re: 2.4 is finally here :)

Postby Noctaro » Tue Apr 28, 2015 6:03 pm

@Fred
Did you try my solution a few posts above?

Greetz Noc
Noctaro
 
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am

Re: 2.4 is finally here :)

Postby Leo » Thu May 14, 2015 9:13 am

@Alex: r1771 "replace some pinMode() by direct DDR port manipulation"

What is the advantage?
User avatar
Leo
 
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany

Re: 2.4 is finally here :)

Postby FengShuiDrone » Thu May 14, 2015 1:35 pm

Fredasss wrote:Hi everybody,
I stuck in the same way with my MTK GPS.
I've just bought a HK multiwii pro, and updated it to 2.4,
I tried these settings:

#define SERIAL2_COM_SPEED 57600 //also tried standart baudrate
#define GPS_SERIAL 2
#define GPS_BAUD 57600
#define NMEA
#define INIT_MTK_GPS

tried to change baud rate, but nothing appened in the GUI.
can you please help me to find a way to make it work ?
thanks by advance.

Fred

Change your serial baud to 115200. Leave GPS baud at 57600. Only use these settings on First firmware upload:
#define SERIAL2_COM_SPEED 57600
#define GPS_SERIAL 2
#define GPS_BAUD 57600
#define INIT_MTK_GPS

Use these settings on SECOND upload:
#define SERIAL2_COM_SPEED 57600
#define GPS_SERIAL 2
#define GPS_BAUD 57600
#define NMEA
On the second upload, re-comment the #define INIT_MTK_GPS statement so it looks like this again.
//#define INIT_MTK_GPS

The statement #define INIT_MTK_GPS
is what initializes the module. After initialization you must re comment this on second upload by adding // in front.
Make sure that your TX lead on the module goes to the RX pin on the FC. Make sure that RX lad on module goes to TX pin on FC. The following step is IMPORTANT! Make sure in your Arduino sketch in the GPS section that the following:
#define USE_MSP_WP
is not commented (commenting is adding the two slashes.)
Make sure that your failsafe is enabled before using GPS (or on any other flight for that matter.)
FengShuiDrone
 
Posts: 234
Joined: Wed Dec 24, 2014 1:20 am
Location: ......

Re: 2.4 is finally here :)

Postby carlonb » Thu May 14, 2015 8:29 pm

Leo wrote:@Alex: r1771 "replace some pinMode() by direct DDR port manipulation"

What is the advantage?

+1
If there aren't advantages I preferred as it was before because more easy to read/understand.
My 2 cents :)
carlonb
 
Posts: 209
Joined: Sun Apr 03, 2011 6:29 pm

Re: 2.4 is finally here :)

Postby Alexinparis » Fri May 15, 2015 12:22 am

Leo wrote:@Alex: r1771 "replace some pinMode() by direct DDR port manipulation"

What is the advantage?


Hi,

This is the same principle as writing for instance on a mega: PORTF|= 1<<7; instead of digitalWrite(A0, HIGH)
For digitalWrite, the advantage is obvious: much faster.

For pinMode, as it is required only once, the speed is not so important.
But removing every call of pinMode (which is still not the case, and still to do in Output.cpp) could free something like 350 bytes.

Arduino pinMode code for reference:
Code: Select all
void pinMode(uint8_t pin, uint8_t mode)
{
   uint8_t bit = digitalPinToBitMask(pin);
   uint8_t port = digitalPinToPort(pin);
   volatile uint8_t *reg, *out;

   if (port == NOT_A_PIN) return;

   // JWS: can I let the optimizer do this?
   reg = portModeRegister(port);
   out = portOutputRegister(port);

   if (mode == INPUT) {
      uint8_t oldSREG = SREG;
                cli();
      *reg &= ~bit;
      *out &= ~bit;
      SREG = oldSREG;
   } else if (mode == INPUT_PULLUP) {
      uint8_t oldSREG = SREG;
                cli();
      *reg &= ~bit;
      *out |= bit;
      SREG = oldSREG;
   } else {
      uint8_t oldSREG = SREG;
                cli();
      *reg |= bit;
      SREG = oldSREG;
   }
}
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: 2.4 is finally here :) Buzzer Question

Postby Carl334 » Mon May 18, 2015 12:34 pm

Multiwii 2.4 I've a onboard LiPo LED and I installed a buzzer.
It buzzes on certain actions from the TX.
My question why doesn't it buzz on ARMED/DIS_ARMED? Do I just have to rely on seeing the LED?
Carl334

Posts: 9
Joined: Mon Jan 12, 2015 10:01 am
Carl334
 
Posts: 15
Joined: Mon Jan 12, 2015 4:01 pm

Re: 2.4 is finally here :)

Postby HeliHaven » Sun May 24, 2015 7:41 pm

I have just updated a MultiWii Pro to Ver. 2.4 and am having a problem with connecting to WinGUI latest version.

First problem was a software mis-match as it was expecting Ver 230, but is seeing Ver.240. That was an easy fix in MultiWii.h as usual.
On loading the sketch to the board again, on connecting, it throws up the Navi Version error: "GUI Version: v7. Controller version: v5. Navigation Functions Disabled."
Clicking OK, the board connects and all is working - GPS working fine with sat. locks, (8 indoors with an MTK!!!) but obviously no mission capability and mission buttons are disabled, as would be expected
If I change the MultiWii.h to: #define NAVI_VERSION 7 //This allow sync with GUI, on attempting to connect to the WinGUI I get a program error "Unhandled exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue." etc.
The error message begins with "Value of '15' is not valid for 'Value'. 'Value' should be between 'Minimum' and 'Maximum'. Parameter name: Value." indication an out of range error relating to the .net framework I assume?

Has anyone else come across this and found a solution at all?

Thanks in advance for any help.
HeliHaven
 
Posts: 3
Joined: Thu Jul 24, 2014 11:27 pm

Next

Return to Software development

Who is online

Users browsing this forum: No registered users and 2 guests