Developer

APM:Plane 3.5.2 released

3689651507?profile=originalThe 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!

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • thanks marc :) will defo upgrade asap. One problem I have noticed is accelerometer inconsistency errors that stop me arming. I havent been able to fly/test too many times yet as its a new plane, but in the very few tests i have done, leaving the plane for a few mins completly unarmed (as in not even pressing the red arm button) then after a few mins press the red arm button then try and arm i get a green light. However if i power up, press the red arm button straight away, then wait a similar amount of time and try to arm i cant as get the accelerometer inconsistency error. Could be just coincidence so will do some more testing. Anyone else seen this error on 3.5.x?

  • Phil, 3.5.2 fixes at least one crash bug, so it's good to upgrade.

    Major version upgrades are the ones that are a bit more risky.

    You will not need to set anything up again, you can just upgrade and fly, athough making sure that FBWA moves your servos properly before takeoff is always good :)

  • Cool thanks Andrew!
  • Developer

    @Phil, it is fine (and recommended!) to go from 3.5.0 to 3.5.2 with no configuration or recalibration change.

    If there is a need to recalibrate then I will either make it clear in the announcement, or I will make it a major version change.

    Cheers, Tridge

  • How important is it to upgrade from 3.5.0 to 3.5.2? My plane seems OK on 3.5.0 so do I need to upgrade? Also if I upgrade minor versions like 3.5.9 to 3.5.2 as opposed to 3.4 to 3.5 do I need to set everything up again from scratch or can I just upgraded and fly? Quite new to arduplane :) thanks.
  • Awesome!

  • Moderator

    Thank you, Tridge, much appreciated. I still have one or two logs of unexplained crashes but it sounds like maybe the new code could have prevented whatever caused those too. Good stuff.

  • Developer

    @Graham, I've replied in that old message on the RTL crash. It was caused by a failure of the Y gyro on the MPU6000. If the 3.5.x code had been used then the dual-EKF would have detected this and I believe the flight would have proceeded without problem.

  • @Tridge

    Thank you so much.

  • Developer

    @Anthony, we do have basic docs on all Q_* parameters here:

    http://ardupilot.org/plane/docs/parameters.html#q-parameters

    I've also recently documented all of the frame type options here:

    http://ardupilot.org/plane/docs/quadplane-support.html#frame-setup

    Complete Parameter List — Plane documentation
This reply was deleted.