Developer

APM:Plane 3.0.2 released

3689591584?profile=original
The ardupilot development team is proud to announce the release of version 3.0.2 of APM:Plane. This release combines some important bug fixes with some new features.

I2C bug fix

The most important change for this release is a bug fix for an I2C bug in the NuttX I2C driver code that would (under some rare circumstances) cause a Pixhawk to crash. This bug fix is the primary reason for doing a new release now.

This bug was able to be reproduced by creating a 1.3m GPS cable carrying both the I2C signals for a magnetometer and the UART signals for the GPS. Interference between these two signals could cause the I2C controller to give spurious data to the I2C driver. The I2C driver did not have sufficient protection against these errors and could crash the board.

While we have not been able to reproduce this error with the normal cables that come with a Pixhawk we cannot rule out the bug triggering with shorter cables, so we are doing a fast release to fix the bug.

Autotune

This release also includes an important new feature - automatic roll/pitch tuning. While this feature is still considered experimental we have had very positive feedback from beta testers and have decided to include it in the release.

Full documentation for how to use automatic tuning is available here:

http://plane.ardupilot.com/wiki/automatic-tuning-with-autotune/

we hope that the automatic tuning will help users who have had difficulty with the standard APM:Plane manual tuning procedure. We plan on extending autotune to other aspects of fixed wing tuning in future releases.

Other changes
  • fixed a glide slope calculation error when very close to waypoints
  • fixed a bug when swithing to another auto-throttle mode during auto takeoff (thanks to Marco for finding this bug!)
  • added MIS_AUTORESET parameter (thanks to Andrew Chapman)
  • support compassmot calibration by supplying current measurments to the compass driver (thanks to Jon Challinger)
  • fixed a GPS driver bug that could cause GPS lag in case of lost GPS samples (thanks to Jon Challinger)
  • fixed a LOITER_TURNS bug in missions for counter-clockwise loiter (thanks to Iskess for finding this bug)
  • added support for OBC termination requirements to PX4IO
  • added support for pressure altitude termination to OBC module
  • fixed EKF wind estimation with no airspeed sensor (thanks to Paul Riseborough)
  • improved tuning of EKF for fixed wing aircraft (thanks to Paul Riseborough)
  • Converted rally point code to library AP_Rally (thanks to Andrew Chapman
  • added SITL checking for numerical errors

Thanks to testers!

Many thanks to everyone who tested the beta versions of this release! Special thanks to Marco, Paul, Jon, Iam, JNJO, sonicdahousecat and Keeyen for providing testing of both existing features and the new autotune code.

Happy flying!
E-mail me when people leave their comments –

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

Join diydrones

Comments

  • Developer

    Today over 40 flight with this 3.0.2, i just can say "wow", super stable, zero issue found.

  • Developer

    @Dave,

    It detects rate overshoot, which is usually the root cause of oscillation. Oscillation is usually what people call going past the desired attitude, whereas rate overshoot is when it goes past the desired rate of change of attitude.

    It really is a simple (also known as dumb!) algorithm, but it is also quite robust which is why we chose it for a first attempt at autotune.

    One thing it doesn't know however is what the airframe is actually capable of. That is one of the main reasons for AUTOTUNE_LEVEL. An autotuner really needs to know if an airframe really is capable of some particular roll rate. By asking the user to put in an AUTOTUNE_LEVEL we get a rough idea of whether its a 3D twitchy plane with hyper-fast servos, or a foam glider with wimpy cheap analog servos. If the user sets level 9 and the plane isn't capable of that sort of twitchy attitude change they are likely to be unhappy with the result.

    Cheers, Tridge

  • Developer

    Hi Rana,

    It's very common to need more channels on a plane, for example for flaps, fence enable, mission reset, choke, ignition cut, landing gear control etc etc.

    I know many people do have a spare channel or even several spare channels, and for those people I would like to add functionality similar to ch6/ch7 on copter, but I didn't want to rely on that for autotune.

    Cheers, Tridge

  • Hi Tridge !

    "The reason we didn't do it for autotune is that we wanted autotune to be usable by everyone, including people with 6 channel transmitters that are already using all their channels."

    I am using six ch radio also with Arducopter 3.1.3, and the receiver has out. I have a three position switch on ch6 (knob converted into 3-pos switch) and 2position switch on gear ch 5.

    I have configured in the code so that APM extract from the ppm stream and put my ch6 (3-position switch ) to Arducopter's input ch5 and similarly the gear ch5 (2-position switch) to Arducopter's input channel 7 for auto tune.

    // g.rc_5.set_pwm(periods[4]); //original channel 5
    // g.rc_6.set_pwm(periods[5]); //original channel 6
       g.rc_5.set_pwm(periods[5]); //channel 5 is mapped to ch 6
       g.rc_6.set_pwm(periods[6]); //channel 6 is mapped to ch 7
    // g.rc_7.set_pwm(periods[6]); //new channel 5 original
       g.rc_7.set_pwm(periods[4]); // Ch 7 is mapped to ch 5, for auto tune

    Its working just great in Arducopter and I want to use in Arduplane, but could not find, pls support.

  • Developer

    @Dave,

    The autotune works by looking at the demanded versus achieved rate. So if we look at roll tuning, then it is the demanded rate of change of roll attitude (in degrees per second) versus that the X gyro is indicating (also in degrees/second).

    Whenever the plane is flying in a mode that has roll stabilisation it will be demanding some level of roll rate, even if it is zero. The tuner kicks in whenever the demanded roll rate goes past 80% of the maximum roll rate. So if the max roll rate is configured as 60 degrees/second and the plane tries to correct its attitude at 50 degrees/second then it will use the response of the aircraft to learn a bit more about roll tuning.

    So any rapid stick movement by the pilot is sufficient for autotune to kick in and learn something.

    Cheers, Tridge

  • Developer

    @Bjorn,

    yes, we will add an equivalent to ch6/ch7 controls in APM:Plane, although we'll make the channel numbers configurable. It just hasn't been done yet. The reason we didn't do it for autotune is that we wanted autotune to be usable by everyone, including people with 6 channel transmitters that are already using all their channels.

    Cheers, Tridge

  • Developer

    @Dave,

    Either will work. It really depends on your preferred flying style.

    The stick movements do need to be quite fast though. You need to ensure the autopilot is trying to change attitude as fast as it can.

    Cheers, Tridge

  • one thin i miss is to use ch.6 or 7 or any othe channal for ie. rtl or acro/takeoff.  like the copter firmware. 

  • Today, the first calm day that I' have to check 3.01 and the sky walker flies nice in perfect loiter circle, mission just above the yellow line, I don't shure what change but it's another plane THAAAANK'S.

    Next flight I try 3.02  :)  

  • Developer

    @Hector, autotune works on all board types, including APM2

    Cheers, Tridge

This reply was deleted.