[octavvian]

 , no problem, I price more the advantages gain by the next branch over the diagnostic led (sincerely if you have telemetry, the need for WS281x led is kinda redundant and less clear for a true diagnostic), but was nice to see it work.
The second issue that I had was that with next 335 fw, after calibrating and everything, no orange/red, the copter fly nicely
but switched to alt hold, with all setting default, it drops from the sky. Any idea about that kind of behavior?

[octavvian]

Tested with next 423, stabilized OK, INS13 indoor OK as long the mag warnings don't kick in, althold drops from the sky 1 m or so, is recovering, is twitching....?! so back to 16.09, disappointed. 

[TheOtherCliff]

Help me understand what I need to set up to get this to happen.  Can I just set up Attitude with Manual thrust and Attitude with AltitudeHold thrust and see this happen?  I don't often use AltitudeHold, I usually use AltitudeVario.

[TheOtherCliff]

If you have time to test, here are the commits that are related to this and might have broken it.

A quick glance at the code and it looks like the last one of three (most recent) is the one that broke it.  Try that commit (should be broken) and the one before it (should work OK).  You can just back out that commit from your recent next and have everything working well.

I would also treat the first two commits as one, that is, don't bother to test each separately.  Test the commit before the first one and the commit of the second one.

commit 814a882a1dc0d8d938759cef5e7e902eb568c1e1
Date:   Sat Dec 10 09:09:53 2016 +0100
    LP-289 Manage kp=0 in PIDControlDown::UpdateParameters()

commit edd3b8689ba48a7d9c12d56ee344b3a79ee15769
Date:   Sat Dec 10 12:43:50 2016 +0100
    LP-289 Further clean up of PIDControlDown::UpdateParameters()

commit fb5f9034eab3ba32f8408b2f4b1a7a5a40ecf644
Date:   Thu Mar 9 18:48:36 2017 +0100
    LP-289 prevent initialization with non-zero pid->I accumulator (dangerous if kI is low)

[octavvian]

Hi, please understand, I didn't modify much the settings when moved from 16.06 to next branch, maybe a few adjustment, but nothing major.
I attached the 2 files containing settings. Further more altitude hold tuning is left default in the next branch just to see the difference between the two fw. In 16.09, altitude hold is tuned down because the copter is jumping.

[TheOtherCliff]

You didn't comment...

It looks like this commit is what broke it:
fb5f9034eab3ba32f8408b2f4b1a7a5a40ecf644

$ git diff ebc4b16d9a613ad48037a567554dccbbdc327a43 dcb3d760db41665584fa1497a65693158203e152 flight/libraries/math/pid.c
diff --git a/flight/libraries/math/pid.c b/flight/libraries/math/pid.c
index 4fba369..32f386f 100644
--- a/flight/libraries/math/pid.c
+++ b/flight/libraries/math/pid.c
@@ -6,7 +6,7 @@
  * @{
  *
  * @file       pid.c
- * @author     The LibrePilot Project, http://www.librepilot.org Copyright (C) 2016.
+ * @author     The LibrePilot Project, http://www.librepilot.org Copyright (C) 2017.
  *             The OpenPilot Team, http://www.openpilot.org Copyright (C) 2012.
  * @brief      Methods to work with PID structure
  *
@@ -221,7 +221,10 @@ float pid2_apply(
         pid->D    = 0.0f;
 
         // t=0, u=u0, y=y0, v=u
-        pid->I    = (pid->u0 - pid->va) / pid->vb - pid->kp * (pid->beta * r - y);
+        // pid->I = (pid->u0 - pid->va) / pid->vb - pid->kp * (pid->beta * r - y);
+        // this is dangerous, if pid->I starts nonzero with very low or zero kI, then
+        // it will never settle!
+        pid->I = 0.0f;
     }
 
     // compute proportional part

[octavvian]

Thanks, I'll try it. For now I'm back to 16.09.