The ArduPilot development team is proud to announce the release of version 3.5.2 of APM:Plane. This is a minor release with small changes.

The main reason for this release over the recent 3.5.1 release is a fix for a bug where the px4io co-processor on a Pixhawk can run out of memory while booting. This causes the board to be unresponsive on boot. It only happens if you have a more complex servo setup and is caused by too much memory used by the IO failsafe mixer.

The second motivation for this release is to fix an issue where during a geofence altitude failsafe that happens at low speed an aircraft may dive much further than it should to gain speed. This only happened if the thrust line of the aircraft combined with low pitch integrator gain led to the aircraft not compensating sufficiently with elevator at full throttle in a TECS underspeed state. To fix this two changes have been made:

  • a minimum level of integrator in the pitch controller has been added. This level has a sufficiently small time constant to avoid the problem with the TECS controller in an underspeed state.
  • the underspeed state in TECS has been modified so that underspeed can end before the full target altitude has been reached, as long as the airspeed has risen sufficiently past the minimum airspeed for a sufficient period of time (by 15% above minimum airspeed for 3 seconds).

Many thanks to Marc Merlin for reporting this bug!

The default P gains for both roll and pitch have also been raised from 0.4 to 0.6. This is to help for users that fly with the default parameters. A value of 0.6 is safe for all aircraft that I have analysed logs for.

The default gains and filter frequencies of the QuadPlane code have also been adjusted to better reflect the types of aircraft users have been building.

Other changes include:

  • improved QuadPlane logging for better analysis and tuning (adding RATE and QTUN messages)
  • fixed a bug introduced in 3.5.1 in rangefinder landing
  • added TECS logging of speed_weight and flags
  • improvements to the lsm303d driver for Linux
  • improvements to the waf build system

Happy flying!

Views: 17827

3D Robotics
Comment by Chris Anderson on March 25, 2016 at 9:12pm

What's particularly impressive about this particular bug fix (which is actually more an edge case) is that it was reported just once and the team rather than simply dismissing it as a very unusual series of conditions and events that was unlikely to happen again, decided that it represented an opportunity to make the code more robust. That's the sign of a really responsive dev team and a commitment to code quality that will benefit all of us, even if this edge case never crops again. Bravo. 

Comment by Andrew Tridgell on March 25, 2016 at 9:21pm

Chris, while I appreciate the kind words, it isn't quite as impressive as it seems!

Marc originally reported the bug based on a near-miss he had in mid December. I spent quite a few hours analysing it, but didn't come to a firm conclusion as to the cause. Marc was then bitten by this bug again on the 21st of March and had a nasty crash as a result. Luckily the log of that crash made the problem a lot clearer, and helped Paul and me work out a strategy for fixing it.

So I'm glad its fixed, but I really should have been able to find a fix without Marc having to spend the time building a new plane!

Comment by titeuf007 on March 26, 2016 at 6:00am

thanks tridge and others members for you hard working on this project

Comment by Jason Franciosa on March 26, 2016 at 11:36am

@Tridge, Sorry for the delay, where I am is Semana Santa and the entire country is on vacation and I didn't have access to my workshop.

Just tested 3.5.2 and its working perfect. Thank you again for the quick response and fix! Truly amazing!


Comment by Ravi on March 26, 2016 at 6:29pm

tridge, the problem I am facing is not related to this blog  but may be I can discuss it here. when I do auto air speed ratio calibration the ARSP_OFFSET parameter reaches very high figures of around 400 where as it should be around 2.0. I am using AP3.1.1. because of this problem I am not being able to use airspeed sensor. this happens with pixhawk as well with APM2.6. I am using I2C sensor in pixhawk.

Comment by Andrew Tridgell on March 26, 2016 at 8:39pm

@Ravi, can you post a tlog of the flight? The tlog telemetry log has detailed logging of the ARSPD_AUTOCAL function.

btw, I assume you mean the ARSP_RATIO not the ARSP_OFFSET? The airspeed autocal only learns the ratio, not the offset.

Comment by Hugues on March 27, 2016 at 12:54am

Thx for this update. Must calibration be redone or can we keep the one done in 3.5?

Comment by Andrew Tridgell on March 27, 2016 at 12:59am

@Hughes, calibration is the same - no need to redo it

Comment by Marc MERLIN on March 27, 2016 at 10:11am

Well, what are the odds, thanks Andrew, that was fast.

Just finished building my new plane after 4 days of solid work, I was going to install 3.5.1, and now I see 3.5.2 with your fix. Thanks much. Hopefully the other details and logs I gave you where we discussed the bugs, can help validate if the fix also would have handled the other weird behaviour issues I had and posted there.

If others care about the details:

Comment by Andrew Tridgell on March 27, 2016 at 1:22pm

@Marc, I do hope it helps for you!

The forums have moved now, the new link is:

I will go over those logs from the point of view of the changes that have been made. Hopefully later today. If I don't reply in a couple of days then ping me :-)


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service