Thank you, andyp1per. So, does it mean the default value needs to be changed to previous 0.003?
No, the new default is correct
Hey dev guys, I found that in 4.3.7 (also in 4.4.0 beta3) in FBWA mode all my planes roll completely differently. It doesn’t matter whether auto tuning was done or RLL parameters are default. The plane by the maximum stick deflection does tilt (about up to LIM_ROLL_CD), but after a while (appr. two seconds) it returns back (almost to a level position), so it is not possible to make a turn with a smaller radius. It’s a radical change in control, and as far as I know, it hasn’t been described anywhere. On all controllers I roll back to version 4.3.4, where it works correctly. Please, have a look on this and explain, if there is necessary to change something in settings, or after update to 4.3.7 to do the auto tuning again. But still with the default RLL parameters it would not work correctly - the plain turns only with full rudder together with ailerons and I can’t imagine turning without a rudder. Without a meaningful solution, I will keep the version 4.3.4.
My guess is that this problem has something to do with the EKF3 calculations.
The plane with 4.4.0 beta3 was flying terrible, hard to control/land it by such roll - like described above. I checked two other planes with 4.3.7, those were better but also seemed to roll worse. So I downgraded the first one to 4.3.4 and it flew great, like before with 4.3.4 (no any other change done on the plane).
Today I upgraded the worst one again to 4.3.7 and then to 4.4.0 beta4. It’s incredible, but it flies just as well. If I didn’t see it with my own eyes, I wouldn’t believe it. I really don’t understand how this is possible. During the previous upgrade to 4.3.7 and 4.4.0, something must have been written wrong during the burning process, I guess.
I will double check all other planes with 4.3.7, if they are ok.
@Giorgo without logs we really can’t help you
If I had to take a wild guess then it would be that you are getting inconsistent airspeed estimation on different days, resulting in the STALL_PREVENTION code kicking in to limit bank angle, but that is just a wild guess.
Thank you for your reply. I understand you need logs to estimate potential issue, but just in that plain I have Matek F405, which does not have the SD card and I did not have notebook in the field. There is also no airspeed sensor and compass installed on this plain. But the speed was definitely over 50 km per hour.
This issue is really very strange. As I wrote it could happen after wrong update, but this is again contradicted by the fact that I already did another upgrade to beta2 and beta3 in that bad state. And still it was bad.
So I can only be happy that it works now 
Hi @tridge,
We recently updated Arduplane firmware from v4.2.3 to v4.3.7 and have noticed some intriguing changes in the Fixed-Wing autotune values, particularly in the RLL_RATE_I, RLL_RATE_FF, and RLL_RATE_P parameters.
In our previous configuration (v4.2.3), we observed that after the autotune process, the RLL_RATE_I and RLL_RATE_FF values were consistently identical across all our aircraft. For example, we would have RLL_RATE_I = 0.5849534 and RLL_RATE_FF = 0.5849534 for each aircraft.
However, with the update to Arduplane v4.3.7, we conducted another autotune session, and this time we noticed that the values for RLL_RATE_I, RLL_RATE_FF, and RLL_RATE_P differed from what we observed in the previous version. Specifically, the RLL_RATE_I and RLL_RATE_P values were the same after the autotune, but this behavior was not evident in v4.2.3. For instance, in the latest configuration (v4.3.7), we obtained values such as RLL_RATE_I = 0.1469916, RLL_RATE_FF = 0.4791305, and RLL_RATE_P = 0.1469916.
Given these discrepancies, we are interested in understanding whether there have been any intentional changes to the Autotune algorithm in Arduplane v4.3.7. Alternatively, we are also open to the possibility that the tuning process might not have been executed optimally, leading to these variations.
Thanks
Hi @tridge,
Please, have you ever heard of such a case: On Sunday I was flying one plane normally (Matek F765 WSE, 4.3.7), I landed, changed the battery for the next flight and after the Pre-Arm Safety Checks the engine started beeping and no servos moved. I connected to Mission Planner at home - the same behavior, but there was no error in Messages. Finally, I found out that all the parameters were changed to default. After returning the original parameters back, everything worked normally.
I have found these two logs from that day:
@Giorgo full parameter resets are very rare. We used to get them due to a hardware issue on some boards, but that has been resolved.
If you find a way to reproduce the problem then please let us know, apart from that there isn’t much we can do. It likely was a corrupt flash write to the flash pages that hold the parameters which would trigger an automatic reset on the next boot.
1 Like
I have just released a new stable plane version 4.3.8. This is in parallel with the new 4.4.0 stable release.
The 4.3.8 release has a small number of important fixes since 4.3.7:
- fixed scripting restart bug which could cause a crash on a math error
- fixed RTK injection when first module is a moving baseline BASE
- fixed auto-enable of fence on forced arm when FENCE_AUTOENABLE=3
- fixed a race condition that can cause gyro glitches with notch filtering
- fixed INAxxx battery monitors to allow for battery reset remaining
To update to 4.3.8 using MissionPlanner you will need to do the following:
First choose “All Options” in the Install Firmware screen
then choose STABLE-4.3.8 and the firmware for your board, like this:
Happy flying!
2 Likes