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

  • Moderator

    I had a flight on Saturday where I tested RTL towards the end of an AUTO mission (just a box I use to evaluate tuning). After successfully navigating home and circling home once I exited RTL mode and changed to FBW-A. Then the plane continued on it' merry way not wanting to respond to my commanded aileron inputs. It seemed at some points as though it was responding with a very flat rudder only turn, but no aileron. I then switched to STABILIZE and regained full control and landed. I'm not sure if I missed something on the proper way to exit RTL or if this is a bug in the control logic. When I look at the tlog during the RTL and FBW-A phase, I don't see any input on CH1 though I was definitely applying aileron. Once I switched to STABILIZE everything looks OK. Just to be sure I went back to another tlog where I was flying around in FBW-A and looked to see what the aileron CH1 input looks like and all is normal.

    The tlog 2013-08-17 15-58-07 shows RTL beginning at about 89%

    The tlog 2013-07-31 16-43-44 is for reference and shows normal FBW-A at 22.9% behavior without an RTL preceding it.

    In both examples I am using 2.74 and have mixed in rudder with aileron.

    Regards,

    Nathaniel ~KD2DEY

    2013-08-17 15-58-07.tlog

    2013-07-31 16-43-44.tlog

  • Hi,

    I know this feature request has been asked many times, Cumulative mAh. I will post in the MP forum again too.

    I use two size batteries, a 2200 mAh and a 2650mAh. Fortunately, I can still remember what battery I put in the plane. :-) So, the Cum mAh would allow me to just keep track of that rather than changing the capacity value in MP each time I use a different battery.

    Steven

  • Hi,

    Back from vacation! :)

    With a question: Can i read home altitude trough mavlink?

    Why i ask, is before we wasn't able to read HA directly, so OSD is calculating it now.

    It would simlify the code.

    Thx,

    Gábor

  • pardon if this question has already been asked - i cant seem to find a way to search this thread - but i'm having problems with the new flight modes and minimosd 0.1: ive set up my radio and configured flight mode CRUISE along with my old MANUAL, FBWA and RTL in mission planner. all seems good when i test the modes there; the modes toggles properly in MP as i move the radio switch. furthermore, the behavior of the model (ground testing, i have not tried it in flight yet) makes me think APM really switches modes as it should.

    however, when looking at my FPV video feed, minimosd mode-text does not change properly: whenever i switch to CRUISE from either of MANUAL, FBWA or RTL, minimosd does not update mode status and rather indicates that it is still in the previous mode.

    is anyone else seeing this and are there any known solutions to this problem? i'm not sure if APM sends a string containing the wording of the mode (e.g. "CRUISE") or if it rather sends some binary code that is mapped to the corresponding string inside minimosd, in which case i would need to find the minimosd source code and update its mapping table with the new modes?

  • Hi community,

    My X8 wing ( with APM 2.6 hardware ) is almost ready for maiden fly with parameters as in attached file. My last minute doubt is about  ground calibration: is it mandatory to run "Accel Calibration" ? just one time?

    regards AA

    AlfaHeliX8ver1.param

  • Is there a way to set up differential ailerons in a elevon configuration using the APM elevon mixer?

    I see in the Wiki directions for setting up differential ailerons using discrete aileron servos but I don't see anything when using elevons and the APM mixer.

    Thanks

  • you can question and how do you know without a computer that he remembered the place of take-off? just when you enable RTL he flew to my house and not to the place of take-off

  • I'm sorry for not too firmware specific question. I have a little flying wing, and I can't place APM 2.5 on center of plane. Can I place off axis (max 2-3 inch) the Ardupilot controller? Anyone try it?

    Thanks for help!

    Istvan from Hungary

  • Hi All,

    Yesterday I crashed my model, I really don’t know how it came, I hope someone can shed some light.  See the log file in attachment retrieved from the APM after the model was found. 

    The model has the APM2.5 hardware built in and has been flown a few times using the 2.72 firmware in both in manual mode and in FBWA mode.  A few weeks ago I upgraded to the 2.74b firmware, yesterday was the first flight with this firmware.  The configuration is rather classic except the two ailerons (output channel 6 and 7) on one input channel from the RC transmitter and a V-tail (output channels 2 and 4), futhermore there is no telemetry.
    The weather conditions were excellent: dry, almost no wind  (1…2m/s) from the SW,  22°C and stable atmosphere (no thermals). 

    After the usual and thorough pre-flight checks, both in manual mode and in FBWA mode, the model was switched on and leveled (around 36669400 log time) at the airstrip.  Then it was hand launched (around 36710000 log time) in manual mode.  The model behaved well and was brought to about 150m altitude, still in manual mode.  After a few minutes the FBWA mode was selected on (around 36792600 log time), it dropped 20…30m and was immediately (less than 2 seconds) switched back to manual mode (around 36794600 log time).  Alas to no avail, the model did not responding anymore to the sticks of the transmitter and it hit the ground a few hundred meters away near a near a corn field (around 36798200 log time).  The airframe was total loss (wings and fuselage) but the electronics seem to have resisted.  Strangely enough, a bit before the crash the GPS messages in the log became stalled,  i.e. they did not change anymore and became scarce.

    I have no clue how this happened,  I accept the fact that some setting may have been wrong for the guided modes (FBWA in this case), but then the model still should have been responsive in manual mode.  Could someone please have a quick glance at the logs and suggest a way forward ?  

    Many thanks and best regards,
    Jean.

    2013-08-09 12-58 155.log

  • Help.
    All the plug - entrance turbines 1,3,8 channels. GPS Neo-6.
    The output of 1 channel stuck серву.
    In МишшнПланере all set - all work is drawn is displayed, satellites catches, even trying to steer in the case of RTL.
    However.
    The servo is silent.
    It was silent in any output channel.
    Silent and in manual mode and in RTL.

    Took voltmeter - at the entrances to the 5 volt outputs (at all) about 0 volts.
    Is this normal?

This reply was deleted.

Activity