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

    • Take off your prop for saftey

  • I have RST_MISSION_CH set to channel 9 but it doesn't seem to be working. How can I see the output of the channels above 9? I only see channels 1-8 listed anywhere in MP.
  • Hey again!

    I have done a bit of reading on my altitude CRUISE mode problem and it may be a feature? The FBWB_CLIMB_RATE parameter also controls CRUISE and is set on 2m/s default. On my heavy Twinstar (AUW 1.8kg) that could be a little low. I can also try to shift the CG around. 20m altitude should be gained in 10 sec if holding the elevator fully down on a common aircraft. This is hardly noticible in my case when i fly FPV and press the elevator up or down for one sec. I am changing this in to 8m/s and will try again.

    Another thing, different aircrafts have different rudder throws and that is set by adjusting the radios endpoints. I measured all this on my Twinstar regarding to the Multiplex manual and set my endpoints BEFORE radio calibration. Is this the way to go or shouldnt the APM be limited by endpoints?

  • Is there a param file for a Skywalker 2013 to load as a starting point?  Can the old param file for the skywalker be used for this new TECS firmware.  If anyone has tunned a Skywalker 2013 can you please post the param file or a list of the parameters?  Or are the default settings OK to start with and will need little adjustment?

     

    Thanks for the help!

  • Is it possible to have my gimbal automatically retract on takeoff and landing? So on takeoff, above a certain speed the gimbal would deploy, below a certain altitude the gimbal would retract. Currently I have ch5 setup for manual passthru for this function.

    Thanks

  • Can someone tell me what is wrong with this flight plan? Why won't the DO_JUMP work to create an endless loop? It just goes to RTL after the last waypoint. I tried with the dummy waypoint both before and after the DO_JUMP command.

    3692816534?profile=original

  • I'm having trouble setting up a rudder-elevator only plane. I have set KFF_RDDRMIX to 1. When I switch to FBWA the rudder deflects to one side. This does not happen in stabilize mode.

    I have tried erasing the eeprom and done levelling and radio calibration multiple times. Nothing has helped. The rudder will always offset to one side when KFF_RDDRMIX is anything but zero. CH4 out is somewhere around 1800 ms.

    This issue has stopped me from even trying to tune the pid controllers. Any advice would be appriciated.

  • Hi all,

    Can anyone help me clarify some observations? I have my plane on the bench in stabilize mode, USB or radio connected, and I’m looking at the flight data screen with tuning enabled. I selected pitch and nav pitch to graph (or roll and nav roll). When I move the plane I see the elevator and ailerons act as expected, I see one graph move but the nav * line stays flat. Is this normal? I would expect to see controller output as well, especially since it’s acting on the plane servos. Also from my first flights, all the tlog data seems to have only zeroes for nav pitch and nav roll. In my dataflash data I can see nav pitch and nav roll change as expected. I use most recent software versions, with practically default values everywhere.

    Any comment would be appreciated! Regards, Jan Hein

  • where do I find the radio callibration tab?

    I need it for elevons.

    Another question: the stabiliz mode doesn't work fine, moving the nose up doesn't react in lowering the elevons elevator?!!?!:(

    I can't get the stabilize work fine:(

  • Hi all,

    I try to come up with a smooth waypoint flight but for a couple
    of days I can't make any progress.

    My original problem posted here
    http://diydrones.com/forum/topics/deviation-from-waypoint-track
    still exists. Later I reduced to only 4 waypoints at the corners but
    cycle three times the rectangle.

    I run 2.74b and an EasyStar like plane without ailerons. The
    aileron APM port is connected to rudder. I don't have an airspeed
    sensor and no telemetry on board.

    Today a beautiful day without any wind. I followed all of this thread
    and made the FBW-A tuning first. It looked fine as far as to what I
    understand it should look like.

    Switching over to AUTO will not fly something similar to a rectangle.
    It is overshooting the direct trail between waypoints very much. So
    I'm not really sure if I still have problems within the tuning or
    with waypoint handling.

    I don't want to waste your time but if someone is willing to
    look at the log and give some hints it would be great.

    thanks
    Wolfgang R.

    2013-08-29 09-31 1.log

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @chr1sa: Just a week to go before our next @DIYRobocars race at @circuitlaunch, complete with famous Brazilian BBQ. It's free, fun for k…
yesterday
DIY Robocars via Twitter
How to use the new @donkey_car graphical UI to edit driving data for better training https://www.youtube.com/watch?v=J5-zHNeNebQ
Nov 28
DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
Nov 26
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
Nov 25
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Nov 23
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord: https://discord.gg/EPsZHkg9Nx) https://t.co/PNDewvJdrb
Nov 23
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
Nov 23
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20
DIY Robocars via Twitter
Incredible training performance with Donkeycar https://www.youtube.com/watch?v=9yy7ASttw04
Nov 9
DIY Robocars via Twitter
RT @JoeSpeeds: Sat Nov 6 Virtual DonkeyCar (and other cars, too) Race. So bring any car? @diyrobocars @IndyAChallenge https://t.co/nZQTff5…
Oct 31
DIY Robocars via Twitter
RT @JoeSpeeds: @chr1sa awesomely scary to see in person as our $1M robot almost clipped the walls as it spun at 140mph. But it was also awe…
Oct 29
DIY Robocars via Twitter
RT @chr1sa: Hey, @a1k0n's amazing "localize by the ceiling lights" @diyrobocars made @hackaday! It's consistently been the fastest in our…
Oct 25
DIY Robocars via Twitter
RT @IMS: It’s only fitting that @BostonDynamics Spot is waving the green flag for today’s @IndyAChallenge! Watch LIVE 👉 https://t.co/NtKnO…
Oct 23
DIY Robocars via Twitter
RT @IndyAChallenge: Congratulations to @TU_Muenchen the winners of the historic @IndyAChallenge and $1M. The first autonomous racecar comp…
Oct 23
DIY Robocars via Twitter
RT @JoeSpeeds: 🏎@TU_Muenchen #ROS 2 @EclipseCyclone #DDS #Zenoh 137mph. Saturday 10am EDT @IndyAChallenge @Twitch http://indyautonomouschallenge.com/stream
Oct 23
More…