Developer

APM:Plane 2.74 released

The APM dev team is delighted to announce the release of APM:Plane 2.74, a major new release with a lot of new features. This release is recommended for anyone flying fixed wing aircraft with an APM2 or PX4.

There are a lot of changes in this release, but some of the highlights are:

  • new APM_Control attitude controllers.
  • new TECS speed/height controller from Paul Riseborough.
  • two new flight modes, ACRO and CRUISE
  • new camera trigger by distance system, for better aerial mapping
  • dozens of small fixes and improvements from two months of development
  • lots more documentation, including tuning guides for all the new parameters

Scroll down for a more complete list of changes, but before that I'd like to give you a bit more detail on the highlights above.

New Attitude Controllers

The new "APM_Control" attitude controllers have been in development for a long time. Originally developed by Jon Challinger last year, they were extended by Paul Riseborough and made compatible with the existing parameter names. The key advantage of these new controllers is their improved handling of noise, and much better ability to tune for your aircraft. There is a new tuning guide in the wiki which gives detailed instructions on how to make the most of the new capabilities.

One of the big effects you will see with the new attitude controllers is better handling of pitch compensation in turns. The new PTCH2SRV_RLL parameter makes tuning for flat turns much easier, which has been a major source of frustration in the past.

The new controllers also handle sensor noise much better, especially if you use any D term in your roll or pitch controllers.

New Speed/Height Controller

The new TECS speed/height controller is the second major controller change in this release, and will make a world of difference for aircraft with an airspeed sensor. After a lot of testing I decided to make TECS the default in this release, although you can switch back to the old controllers using the ALT_CTRL_ALG parameter if need be. If for some reason you find you do need these old controllers then please let me know, as I am planning on removing the old controllers in the next release.

The previous airspeed controller for speed/height suffered from a major problem that it gave absolute priority to airspeed. If the aircraft could not achieve the target airspeed you had set then it would dive to gain speed, even to the point of diving into the ground. This made it quite fragile, and you had to be very sure of your airspeed configuration.

The new controller operates over a range of airspeed values, set using the ARSPD_FBW_MIN and ARSPD_FBW_MAX parameters. That controller will try to meet both the airspeed and altitude demands of the mission, but if it can't reach the target speed it will happily fly a bit slower, as long as it doesn't get below ARSPD_FBW_MIN. You can control the relative priorities of speed versus height using the TECS_SPDWEIGHT parameter. See the full tuning guide for details.

New ACRO flight mode

After a suggestion from Thomas in the 2.73 release thread, we have added a new ACRO flight mode.

This modes brings rate controlled stabilization to APM:Plane, and should help give you an "on rails" manual flight experience. It is a lot of fun to fly, but it is not for beginners!

We're planning on expanding the ACRO mode in future releases. Right now it is great for "locked in" flying, and also good for loops and handles inverted flight very nicely. It doesn't yet handle knife-edge or prop-hanging.

New CRUISE flight mode

After a suggestion from Hein, we now have a new CRUISE flight mode. This mode is ideal for longer distance flying without a pre-programmed mission. It is like FBWB, but also does ground track heading hold, with heading update via aileron or rudder.

I've been testing CRUISE at my local flying field, and it is the easiest mode to fly in APM. Just steer the plane around the sky, and when you stop steering it locks onto a ground track and holds it. It isn't a good mode for takeoff and landing, but once you are in the air it is great.

New camera trigger system

When using APM for aerial mapping where you want photos taken at regular distances, the previous system was to setup a grid mission with a "camera trigger" mission item at regular intervals within the mission. That worked, but led to overly large and complex missions. You can now just set a single parameter CAM_TRIGG_DIST to the number of meters of flight between photos, and the APM will take care of when to trigger the camera. This makes for much simpler missions, and also works in other flight modes, including FBWB and CRUISE.

Lots of smaller changes

As is usual with a new release after a couple of months of development there were a lot of smaller improvements based on feedback from users. Many thanks to everyone who gave feedback and contributed patches!

Here is a partial list of the changes:

  • added new GND_ALT_OFFSET parameter for ground station barometric correction
  • made it possible to set the failsafe battery voltage and battery level at runtime via parameters
  • added MIXING_GAIN parameter for controlling the elevon and v-tail mixers
  • fixed stick mixing range in AUTO modes  (thanks Soren!)
  • fixed mode logging in dataflash
  • added support for the EagleTree I2C airspeed sensor on PX4
  • added new RCMAP_* parameters for re-mapping control channels (good for DSM and SBUS receivers on PX4)
  • made it possible to configure board orientation at runtime, to make setup easier without rebooting
  • switched to new task scheduler for more accurate internal timing
  • added a new RELAY_PIN parameter for setting up camera trigger via a digital pin
  • added secondary rudder support, useful for when a separate servo is used for a nosewheel and the rudder, or for v-tail planes with nosewheels
  • fixed RTL glide slope when starting above the target RTL altitude. Descent should now be smooth over long distances. Many thanks to Kitsen13 for raising this.
  • fixed a bug with FBWB airspeed control. Many thanks to Gabor for reporting this
  • Added FS_LONG_TIMEOUT and FS_SHORT_TIMEOUT parameters. Many thanks for the suggestion by Aleck
  • fixed handling of deadzone parameters on RC channels. Many thanks to Soren for reporting this
  • many small C++ fixes from NeuroCopter. This sort of detailed review of our code is much appreciated!
  • fixed analog in handling with some unusual devices - thanks to Andi for noticing this!
  • added support for apparent versus true airspeed calculations based on pressure altitude, for better flight control at higher altitudes
  • avoid writing unchanged bytes to EEPROM, for faster updates and less wear on the chip
  • cope better with large yaw changes in the AHRS code
  • improved the reliability of USB connections on PX4
  • added PX4 support for RELAY (thanks to Marco Bauer)
  • fixed handling of high spin rates in AHRS (thanks Jurgen!)
  • removed support for the old APM1 1280 based boards.

This new release has a lot of new features that should improve the flying experience for all APM users. The APM dev teams wishes all APM users many enjoyable flights, and we hope you have as much fun flying this release as we had making it.

Happy flying!

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

Join diydrones

Email me when people reply –

Replies

  • Today one of my servos went broken, and also melted..



    I think the fets got overheated. Motor still works well.



    Also it was a very advanced weather. Strong wind, and very gusty. 34 km/h and around 50 km/h gusts continously.

    So it is true, that it was a hard moment for all the servos.

    It was my right aileron servo. The type is Hitec HS-65HB.


    In close connection with this.

    Can i make the aileron servos see-sawing much less?



    Please give me advices. :)



    Thx,
    Gábor

  • Tridges text above states that 2.74b added a new parameter called GND_ALT_OFFSET that is used for ground station barometric correction. How do I use this?

    Here is what the wiki says:

    altitude offset in meters added to barometric altitude. This is used to allow for automatic adjustment of the base barometric altitude by a ground station equipped with a barometer. The value is added to the barometric altitude read by the aircraft. It is automatically reset to 0 when the barometer is calibrated on each reboot or when a preflight calibration is performed.

    Do I need to have a barometer attached to MP somehow? How would one do that?

    If I need to manually adjust this parameter how would I figure out what to enter?

    I need to fly an exact altitude above sea level. In aviation we always enter a local barometric altimeter setting to achieve an accurate altitude. Standard pressure is 1013 hpa or 29.92". How can I achieve a similar adjustment on the APM?

     

  • I posted a question about how to use CONDITION_CHANGE_ALT. http://diydrones.com/forum/topics/using-condition-change-alt-to-ach...

     I haven't recieved any replies yet after a couple of weeks. Can anyone clue me in on this function?

    Thank you

     

  • Below is my Nav_Pitch vs. Pitch. I am using airspeed sensor (calibrated).

    According to wiki (extras below) I need to adjust PTCH2SRV_P or PTCH2SRV_I in order both to match as amplitude.

    On my case, is looks Pitch (yellow), exceeds Nav_Pitch (blue). 

    What is your experience on this? Or maybe I can try to trim the elevator server (now I am on middle - 3 holes). Is that a good idea?

    When flying in FBW-A or Loiter, is looks real pitch is like bumping and in loiter it loose altitude progresivelly, then it increase abrupt the altitude to previous values.

    Roll and Nav_Roll both are OK.

    "If you get pitch angle  oscillation or overshoot, then you need to reduce PTCH2SRV_P."

    "Check for any steady offset between nav_pitch-roll and pitch. If you have followed the basic method you may see an offset which can be removed by setting PTCH2SRV_I to a small value (say 0.05) which will allow the control loop to slowly trim the elevator demand to remove the steady error. The value of PTCH2SRV_I can be increased in small increments of 0.05 until you are satisfied with the speed at which the control loop ‘re-trims’."

    3692859280?profile=original

  • First, thanks to all you question askers. You may not know it but your questions help a lot of people or I should say the answers to your questions do. :-)

    Now I have a few of my own. I am down to some fine tuning stuff that I need help on.

    1. On both my planes, when I hit a WP, the throttle appears to go momentarily to zero and ramps back up during the turn. I have messed with the slew rate for throttle to no avail. Any insight appreciated.

    2. On my newest plane, a Skywalker that I am still FINE tuning, I find the WP turn way to abrupt. I've gone through the tuning procedure and all is a specified. How to make a more gentle and graceful turn? WP radius set at about 80m.

    3. This may sound like a dumb question after all these flights but is the Loiter Radius, WP Radius and Default Alt only available in meters on the Flight Planning screen in MP? That is, even if one has checked Imperial? If so, this should change in some future revision. Conversions are an unnecessary cause for error.

    4. For those upgrading MP beware. I reached a new altitude record inadvertently by not noticing that the last two revisions changed units from imperial to metric. Past revisions have left the Planner defaults as is. From now on, I will always check all screens to be sure nothing changed. A mile up uses a lot of battery btw. :))

    Steven

  • I had a crash the other day with my Skywalker X8 that I'm a little confused by.  I've attached the dataflash log.  I was flying in Manual and wanted to walk back to my ground station, so I had my copilot use MP and send the APM "Circle" so that I could walk back, get my FPV goggles on, and fly around.

    The command to Circle took the throttle to 75% (could have sworn I limited to 65%) and a rapid pitch up, then it started to level.  It attempted the circle but was losing altitude gradually.  As it got close to a big hill I thought to myself, "Ok, this isn't going to go well."  So I used the radio to flip from Manual, to Auto and back to manual, pretty rapidly - with the expectation that this would override MP's Circle cmd, but the APM did not come out of Circle and ultimately kissed the ground.

    I know the airplane isn't tuned yet, we're still working on that, but I was hoping Circle would at least attempt to circle somewhat to give me enough time to get sat down and ready to resume control.  Is there any way to determine why Circle continuously lost altitude?  Is this an airspeed sensor problem?  Other things have happened that causes me to question this sensor, so I've bought a new one to install in the new X8 that is on its way.

    Also, why didn't the APM come out of Circle, and is it normal to expect the APM to ignore "nudge" commands from the transmitter while in circle?

    2013-10-15 12-18 40.log

    https://storage.ning.com/topology/rest/1.0/file/get/3692858161?profile=original
  • Hi all,

    just out of curiousity (and possibly saving my plane from a tree landing): what happens if the altitude of a next waypoint is higher then the plane can reach with it's max climb rate? Will it fly to this next WP and circle up? Or is this situation already detected at the first waypoint? How will APM solve this, what flight pattern will result?

    Thanks in advance!

  • Nathaniel Caner 

    thanks for the reply, I am using Airspeed sensor, I have a plane stable enough not to spin, with AOA angle high and low speed.

    I would like that the plane landed as shown in the picture.

    thanks
    jimmy

    3692856413?profile=original 

  •  hello Tridgell, I've been doing tests AUTO LAND, and I see that there is a need to schedule two additional commands: angle of attack and landing speed.
    is possible to add these options in a future version?

    thanks
    jimmy

  • Developer

    Hi,

    Can someone point me to a changelog for the upcoming 2.75 if is there one? 

    And a question, I saw Tridge posting this for the 2.75. 

    • add a way to enable the camera trigger distance in a mission

    Isn't this working for the Arduplane? Is it the CAM_TRIGG_DIST function? Like in this tutorial: 

    http://diydrones.com/profiles/blogs/apm-to-chdk-camera-link-tutorial

    In the new mission planner, with SURVEY, we have the trigger options tab, does it not work with arduplane?

    Thanks 

This reply was deleted.

Activity