MultiWii 2.0 bug report

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
User avatar
mbrak
Posts: 136
Joined: Sat Dec 03, 2011 8:08 pm
Location: Germany, Lemgo

Re: MultiWii 2.0 bug report

Post by mbrak »

Alexinparis wrote:
warthox wrote:it seems that the lpf for the mpu6050 has not a bit of effect.


Hi,
It's possible as I never used a LPF setting on my multis.
I will check, it's maybe a problem of register setting order.



hi

is there any solution for this problem?
my quad with flydiuno MPU6050 has the same problem as wartho described before.
would be great if anyone could solve the problem.

br michael

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

Re: MultiWii 2.0 bug report

Post by Alexinparis »

Hamburger wrote:for OCTOFLATP I did receive the following bug report via email from Michael Geuer:
#define OCTOFLATP ausgewählt. Aber im Config ist Roll und Pitch falsch und es steht auch noch OctoX im Tool

which imho boils down to:
for OCTOFLATP, the GUI displays OctoX instead and roll and pitch are wrong (switched?)

Hope it makes sense to someone - I have nothing bigger than TRIs.


It's just the GUI which is generic for all octo configs and display OCTOCOPTER X8 for all configs.
I will switch it to the generic term "OCTOCOPTER"

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

Re: MultiWii 2.0 bug report

Post by Alexinparis »

Joachim08 wrote:
Alexinparis wrote:
Hi,
can you try to remove this line in multiwii.ino (from 2.0):

Code: Select all

      PTerm = constrain(PTerm,-D8[PIDLEVEL]*5,+D8[PIDLEVEL]*5);

With this, you should have exactly the same behavior of 1.9 stable mode.

can you ensure also that when the multi is reverted, Z ACC is negative and equal in absolute to the value it has when the multi is flat and not reverted ?


Alex,

regarding the tbe i have just downloaded 2.0dev of 14. April. It looks like you have changed the line in multiwii.ino already.
The Z ACC is around 512 when it is flat on the ground and - (minus) 524 when it is reverted.

Is that ok so far ?

When i start the copter in my hands it looks much better now, but i cannot fly because of windy weather outside, maybe
i can give it a try later this evening.

Is there any reason why you have not included the code for the new Drotek IMU 10DOF with MP6050 in the sketch ?


Your ACC value seems to be correct.
Please look better. The line I suggested to remove is still present in the current dev version... and nothing changed regarding the ACC stability.

jhoexp
Posts: 14
Joined: Sun Jan 30, 2011 12:46 am

Re: MultiWii 2.0 bug report

Post by jhoexp »

mbrak wrote:is there any solution for this problem?
my quad with flydiuno MPU6050 has the same problem as wartho described before.
would be great if anyone could solve the problem.

br michael


Same problem here, tried a friend's quad with atmega-328 and mpu-6050 after a good 20minutes bench tuning. It was barely flyable with very low P and high D, and only in hovering/slow manouvers.
Gyro were too sensible and seem to resonate at some frequency, making it impossible to sustain heigh and very hard to tune.
LPF filter has no effect.

Please check the full-range scale too. We really don't need the 2000 °/sec, 1000 or 500°/s should be better. (I think that is the "problem" with itg32XX too, it's just too sensitive, while old good wmp's idg600 gives a better feeling in slow flying and for AP purposes)

warthox
Posts: 65
Joined: Sat Jan 29, 2011 10:05 pm

Re: MultiWii 2.0 bug report

Post by warthox »

jhoexp wrote:Please check the full-range scale too. We really don't need the 2000 °/sec, 1000 or 500°/s should be better. (I think that is the "problem" with itg32XX too, it's just too sensitive, while old good wmp's idg600 gives a better feeling in slow flying and for AP purposes)


are u sure that we dont need the full scale? ;)
maybe u dont need it but some others need it.
so the best solution would be a define for it to select the scale depending on your flying style.

@ alex - did u already had the time to take a look onto the mpu lpf?

jhoexp
Posts: 14
Joined: Sun Jan 30, 2011 12:46 am

Re: MultiWii 2.0 bug report

Post by jhoexp »

warthox wrote:are u sure that we dont need the full scale? ;)


Of course you can set it to what you want, but you don't need 2000°/s, expecially for AP purposes.
Anyway, setting the full range scale to 500°/sec doesn't prevent you to flip it even much faster, prroves is that you can do that with wmp's idg500 and they are just 500°/s.

User avatar
mbrak
Posts: 136
Joined: Sat Dec 03, 2011 8:08 pm
Location: Germany, Lemgo

Re: MultiWii 2.0 bug report

Post by mbrak »

hi

about the problem with the mpu6050 (not very stable, laggy,etc.).....

try out with p=9.0/I=0.04/D=23

just came in from testflight with these settings. very very stable. just wobbling just a tiny bit.

wow. and this with the promini without 11bit pwm.... i am impressed!

the values are from rosewhite. 10 minutes bevore i couldnt believe that they are real... now i know that they are!

Kayle
Posts: 141
Joined: Sun Feb 13, 2011 6:45 pm

Re: MultiWii 2.0 bug report

Post by Kayle »

Hi,

try out with p=9.0/I=0.04/D=23


Auf welchen Achsen ? Allen drei ?

Gruß Kayle

fax8
Posts: 61
Joined: Mon Feb 14, 2011 5:29 pm

Re: MultiWii 2.0 bug report

Post by fax8 »

jhoexp wrote:LPF filter has no effect.


While troubleshooting the same quad jhoexp is referring above (we are common friends) we discovered that with current code, it seems that DLPF settings are not stored in the sensor memory thus never actually used by the sensor and completely useless. More details, including working code, at viewtopic.php?f=8&t=1591

Fabio Varesano

bitman
Posts: 3
Joined: Tue Apr 24, 2012 10:53 pm

Re: MultiWii 2.0 bug report

Post by bitman »

Hi all,

I think I have a problem with MultiWii 2.0 firm. I have a multiwiicopter with PARIS 4.0, bma180 and a WMP. I have changued this into config file:

#define QUADP
#define BMA180
#define MOTOR_STOP

#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}

You can see the behavior in this video:

http://www.youtube.com/watch?v=br3-SZr3 ... r_embedded

It's seems like a bug, because with 1.9 firm, everything works fine.

What can I do?

thx

Bye!

User avatar
fr3d
Posts: 97
Joined: Sun Feb 06, 2011 11:21 am
Location: Cappelle la grande near the ch'ti village
Contact:

Re: MultiWii 2.0 bug report

Post by fr3d »

bitman wrote:Hi all,

I think I have a problem with MultiWii 2.0 firm. I have a multiwiicopter with PARIS 4.0, bma180 and a WMP. I have changued this into config file:

#define QUADP
#define BMA180
#define MOTOR_STOP

#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}

You can see the behavior in this video:

http://www.youtube.com/watch?v=br3-SZr3 ... r_embedded

It's seems like a bug, because with 1.9 firm, everything works fine.

What can I do?

thx

Bye!


try to disable bma180

Code: Select all

//#define BMA180 

or add

Code: Select all

#define BMA180_ADDRESS 0x82

bitman
Posts: 3
Joined: Tue Apr 24, 2012 10:53 pm

Re: MultiWii 2.0 bug report

Post by bitman »

I tried to disable BMA180 but It got worst,

But I,ll add this code...let me try...

thx

Bye!

bitman
Posts: 3
Joined: Tue Apr 24, 2012 10:53 pm

Re: MultiWii 2.0 bug report

Post by bitman »

Ok, I,ve tested this:

add BMA180_ADDRESS 0x82 => The same.
add BMA180_ADDRESS 0x82 and #define BMA180 => The same.

And also changued this:

#if !defined(BMA180_ADDRESS)
//#define BMA180_ADDRESS 0x80
#define BMA180_ADDRESS 0x82
#endif

But nothing ocurs. Sometimes ACC doesn't works, others works too bad.

Thx!

Bye

wilco1967
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: MultiWii 2.0 bug report

Post by wilco1967 »

My tri tail servo is mechanically not completely correct.
When flying straight, It needs approx 1560 us on the tail servo as shown in the GUI to keep the heading.

So I tried to trim it by adjusting TRI_YAW_MIDDLE to 1560, but it doesn't seem to do anything
Even tried 1800 (just to see if it would move at all), but no luck. It stays in the same centre position....

I'm using dev20120414, this is with a promini 328
On earlier versions (then with Flyduino mega), it seemed to worked ok.

if I change (in output):

servo[5] = constrain(tri_yaw_middle + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR

to

servo[5] = constrain(1560 + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR

it works ok.....

Seems like the variable tri_yaw_middle gets overwritten somehow, but I cannot find how/where :roll:

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

Re: MultiWii 2.0 bug report

Post by Hamburger »

It is stored in eeprom and can be changed via lcd or via terminal of arduino ide.
Else you can clear eeprom and upload mwii again.

wilco1967
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: MultiWii 2.0 bug report

Post by wilco1967 »

Hamburger wrote:It is stored in eeprom and can be changed via lcd or via terminal of arduino ide.
Else you can clear eeprom and upload mwii again.


Aha !
now I understand......
Thanks Hamburger....

I don't have an LCD, so I never thought about this posibility to use the arduino terminal (serial monitor)....
Took me a while to figure it out, but now I got it working through the serial monitor of arduino

Some steps for so others may also used this.... I fly multiwii for almost one year and did not know, and I think there might be more people like that around.... :roll:

- First ensure #define LCD_CONF is active (not commented)
- select #define LCD_VT100
- upload your program so settings take effect

- open serial monitor in arduino (right top corner)
- select baudrate 115200

- Put pitch stick forward FIRST, and only after that put throttle / yaw stick to bottom right (assuming mode 2).
Please be aware, if you first put the throttle / yaw to bottom right, it will start the motors :!:

On the serial monitor, now the settings should appear
- with pitch up / down, you can scroll through the parameters.
- with roll left / right, you can change parameters.

here I could change the tri_yaw_middle to the required position...

when finished, throttle to left bottom, and pitch forward to save and exit.


See also http://multiwii.googlecode.com/svn/bran ... -57721.pdf for all commands



Wilco.

Cronalex
Posts: 51
Joined: Tue Mar 20, 2012 8:41 pm

Re: MultiWii 2.0 bug report

Post by Cronalex »

I have a multiwii crius SE and I do not work in version 2.0 headfree why? What should I do?

Ausi1972
Posts: 17
Joined: Sat Apr 14, 2012 9:03 pm

Re: MultiWii 2.0 bug report

Post by Ausi1972 »

I have the crius multiwii se and have tried the headfree mode. It works but my aileron is reversed on it, the aileron is fine in stable and acro mode but headfree it is reversed. Is there a setting to reverse it?

Ausi1972
Posts: 17
Joined: Sat Apr 14, 2012 9:03 pm

Re: MultiWii 2.0 bug report

Post by Ausi1972 »

I have just noticed that on my tx the rudder and aileron are reversed which makes it correct in the GUI but I guess I could put them to normal then reverse them in the code?

Ausi1972
Posts: 17
Joined: Sat Apr 14, 2012 9:03 pm

Re: MultiWii 2.0 bug report

Post by Ausi1972 »

Other than that for a super cheap first build quad using the wrong esc's and having lots of vibrations it is still flying very stable and alt works great. It flies on it's own hands off sticks for at least 30secs before it starts to drift away.
I am now in the process of building a much nicer unit with a naze32 and proper Simon esc's. Also might be tempted to put some quality motors on it.

Ausi1972
Posts: 17
Joined: Sat Apr 14, 2012 9:03 pm

Re: MultiWii 2.0 bug report

Post by Ausi1972 »

I am using Multiwii 2.0 (NOT DEV)

I think I may have found a problem either with my config, my Crius SE board or the code (not sure which).

In the Multiwii gui if I switch on only the graph for the mag yaw then rotate the quad there is almost no movement in the line. However if I pitch the quad with only this same same graph line (MAG YAW) goes up and down nicely.
If I only show the pitch or roll for the MAG the lines roll up and down nicely pitch and roll of the quad as expected.

I have calibrated the mag several times, whilst connected via USB to the multiwii GUI I hit the calib mag button then rotate the quad 2 to 3 times on the yaw, roll and pitch axis.

Here is my config.h stuff:
#define QUADX
//#define YAW_DIRECTION -1
#define CRIUS_SE
....
//#define SERVO_TILT
#define TILT_PITCH_MIN 1020 //servo travel min, don't set it below 1020
#define TILT_PITCH_MAX 2000 //servo travel max, max value=2000
#define TILT_PITCH_MIDDLE 1500 //servo neutral value
#define TILT_PITCH_PROP 10 //servo proportional (tied to angle) ; can be negative to invert movement
#define TILT_ROLL_MIN 1020
#define TILT_ROLL_MAX 2000
#define TILT_ROLL_MIDDLE 1500
#define TILT_ROLL_PROP 10
.....
//#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
//#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}
//#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = X; magADC[PITCH] = Y; magADC[YAW] = Z;}
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = X; accADC[PITCH] = Y; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = X; gyroADC[PITCH] = Y; gyroADC[YAW] = Z;}
#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = -Y; magADC[PITCH] = X; magADC[YAW] = Z;}

SovGVD
Posts: 13
Joined: Tue Feb 08, 2011 10:17 pm
Location: Russia
Contact:

Re: MultiWii 2.0 bug report

Post by SovGVD »

wilco1967 wrote:if I change (in output):

servo[5] = constrain(tri_yaw_middle + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR

to

servo[5] = constrain(1560 + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR

it works ok.....

Seems like the variable tri_yaw_middle gets overwritten somehow, but I cannot find how/where :roll:

the same bug, i changed tri_yaw_middle variable to TRI_YAW_MIDDLE (define in config.h)

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

Re: MultiWii 2.0 bug report

Post by Hamburger »

SovGVD wrote:the same bug, i changed tri_yaw_middle variable to TRI_YAW_MIDDLE (define in config.h)

or you could read the two posts following the one you quoted for explanation and usage guide.

Ausi1972
Posts: 17
Joined: Sat Apr 14, 2012 9:03 pm

Re: MultiWii 2.0 bug report

Post by Ausi1972 »

Ausi1972 wrote:I am using Multiwii 2.0 (NOT DEV)

I think I may have found a problem either with my config, my Crius SE board or the code (not sure which).

In the Multiwii gui if I switch on only the graph for the mag yaw then rotate the quad there is almost no movement in the line. However if I pitch the quad with only this same same graph line (MAG YAW) goes up and down nicely.
If I only show the pitch or roll for the MAG the lines roll up and down nicely pitch and roll of the quad as expected.

I have calibrated the mag several times, whilst connected via USB to the multiwii GUI I hit the calib mag button then rotate the quad 2 to 3 times on the yaw, roll and pitch axis.

Here is my config.h stuff:
#define QUADX
//#define YAW_DIRECTION -1
#define CRIUS_SE
....
//#define SERVO_TILT
#define TILT_PITCH_MIN 1020 //servo travel min, don't set it below 1020
#define TILT_PITCH_MAX 2000 //servo travel max, max value=2000
#define TILT_PITCH_MIDDLE 1500 //servo neutral value
#define TILT_PITCH_PROP 10 //servo proportional (tied to angle) ; can be negative to invert movement
#define TILT_ROLL_MIN 1020
#define TILT_ROLL_MAX 2000
#define TILT_ROLL_MIDDLE 1500
#define TILT_ROLL_PROP 10
.....
//#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
//#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}
//#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = X; magADC[PITCH] = Y; magADC[YAW] = Z;}
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = X; accADC[PITCH] = Y; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = X; gyroADC[PITCH] = Y; gyroADC[YAW] = Z;}
#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = -Y; magADC[PITCH] = X; magADC[YAW] = Z;}


Forget all of that. I have just built up again, same motors but with HK F-20A ESC's flashed with Simon code, the Crius MWC SE in a DJI F450 V2 frame.
Been out in the garden with restricted space and found it flies super stable and everything is working perfect now.
Headfree mode is amazing. it makes flying a total breeze, very strange to get used to. No more trying to keep it tail in etc. Just go fly!!!!
Altitude hold is also working great.
Looking forward to a great weekend of flying my new toy!

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: MultiWii 2.0 bug report

Post by Crashpilot1000 »

BTW:
I have NO NUNCHUK in flight bug with MultiWii_dev_20120504. My tri ran on 1.9 before and i skipped the official 2.0, so i can not say, if it was affected with FW 2.0.
viewtopic.php?f=8&t=1455&p=13973#p13973

Y.Mita
Posts: 46
Joined: Thu Sep 15, 2011 11:25 pm

Re: MultiWii 2.0 bug report

Post by Y.Mita »

Seems to find some bugs in 20120504.

I install v2.0 and it works perfect, but 20120504, I can't start CALIB_ACC and CALIB_MAG from MultiWiiConf. Try eeprom_clear but nothing change.
Also from RC stick, I can start MAG calibration, but can't start ACC calibration.
With v2.0, both CALIB_ACC and CALIB_MAG and RC stick ACC caribration and RC stick MAG caribration works well.

Is this something setting error?

My Hexa Flyduino Mega with FreeIMU v0.3.5_MS.

Pyrofer
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: MultiWii 2.0 bug report

Post by Pyrofer »

Hey, I just put the latest 2.0 DEV build on, and noticed I can't trim with the remote anymore!

When I move the sticks I get no response on the LEDs like I did before and it doesn't seem to change anything.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Baro Bug / Solution

Post by Crashpilot1000 »

Hi !

In the current code there are some problems with the locking in of a new hight for the Baro/PID controller:
Original:

Code: Select all

 #if BARO
    if (baroMode) {
      if (abs(rcCommand[THROTTLE]-initialThrottleHold)>20) {
         baroMode = 0; // so that a new althold reference is defined
      }
      rcCommand[THROTTLE] = initialThrottleHold + BaroPID;
    }
  #endif


Problem1:
At the moment the throttlestick is altered a new hight is locked for the PID controller long before the copter could have possibly reached a new hight or has altered his position. This can also lead to a feedbackproblem.

Problem2:
With this code the throttlechannel is rasterized in 21 steps, that gives a sluggish throttleresponse and an unnatural feeling for the pilot.

Possible Solution:
Give the pilot full control over the throttlechannel.
Lock in a new hight for the Baro PID controller only under the following circumstances:
The copter has done a substantial hight (in my code 60cm) change and the pilot wanted it by stickinput (change "20").
I changed the code and tested it for 2 days - and the baro behaviour improved. Perhaps i have to raise the value of "60" for my BMP085 to e.g. "100".
I posted my findings in my german forum (http://fpv-community.de/showthread.php? ... post146766) and another user reports (http://fpv-community.de/showthread.php? ... post146996) that his copter behaves significantly better than with the original DEV 20120504.
My findings should also apply for the new DEV, but is untested.

Please look into this. I think my new code is far from perfect, but it flies better.
I am new to C and arduino programming.

Cheers

Crashpilot1000

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
EDIT 26.05.2012: I did a new Version: http://fpv-community.de/showthread.php? ... post148827
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////


New Code:

Code: Select all

static uint8_t baroloopcounter=0;
static int32_t thrsticksum=0;
static int16_t thrstickmw=0;
static int32_t estaltsum=0;
static int32_t estaltmw=0;


Code: Select all

  #if BARO
    if (baroMode)
    {
      if (baroloopcounter <64)
      {
        estaltsum=estaltsum+EstAlt;
        thrsticksum=thrsticksum+rcCommand[THROTTLE];
        thrstickmw=0;
        estaltmw=0;
        baroloopcounter=baroloopcounter+1;
      }
      else
      {
        baroloopcounter=0;
        estaltmw=estaltsum>>6;
        thrstickmw=thrsticksum>>6;
        estaltsum=0;
        thrsticksum=0;
       
//        debug3=thrstickmw - initialThrottleHold;
//        debug4=estaltmw - AltHold;
       
        if (abs(estaltmw - AltHold)>60 && abs(thrstickmw - initialThrottleHold)>20) //Did the hight significant change over time on purpose?
        {
          baroMode = 0; // so that a new althold reference is defined
        }
       }
     rcCommand[THROTTLE] = rcCommand[THROTTLE] + BaroPID;
    }
  #endif
Last edited by Crashpilot1000 on Sat May 26, 2012 5:50 pm, edited 1 time in total.

User avatar
AlouetteIII
Posts: 27
Joined: Tue Jan 25, 2011 2:34 pm
Location: AU Australia
Contact:

Re: MultiWii 2.0 bug report

Post by AlouetteIII »

@CrashPilot1000 - cool - what BARO PIDs did you have for the best result and have you tried it in combination with Acc Z variations.

which sections to replace the code you show? which tabs? And did you see if this still applies to 2.0.522 version ? thanks

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: MultiWii 2.0 bug report

Post by Crashpilot1000 »

Hi !
I just tried the new MultiWii_dev_20120522 with my code in the backyard and it works very well though its windy here in NW Germany.
The changes are done in the main tab of the code. Just place the new "statics" in front of the others and replace the original code (i quoted under "Original") with the new one. BTW i did my last flight (BMP085 Baro) with ..."abs(estaltmw - AltHold)>100 ..." and "...thrstickmw - initialThrottleHold)>40...". Just play with the values. Uncomment Debug 3 and 4 and watch the values in the GUI. Debug 3 tells you the change of the throttlestick and debug 4 tells you the change of the Altitude in cm of the sensor. You can test it while disarmed. If you see Debug 3=0 the code has locked in a new hight. At the moment i use the stock PID for alt/baro. I looked at the ACCZ values as well, and its beyond my capabilities to make real use of them. At the moment i can figure out with a good probability if the copter was rising or falling while locking a new altitude. This could be used e.g for a small throttleburst to support the Baro.

Post Reply