APM:Plane 3.7.0 released

The ArduPilot development team is proud to announce the release of version 3.7.0 of APM:Plane. This is a major update so please read the notes carefully.

The biggest changes in this release are:

  • more reliable recovery from inverted flight
  • automatic IC engine support
  • Q_ASSIST_ANGLE for stall recovery on quadplanes
  • Pixhawk2 IMU heater support
  • PH2SLIM support
  • AP_Module support
  • Parrot Disco support
  • major VRBrain support merge
  • much faster boot time on Pixhawk

I’ll give a bit of detail on each of these changes before giving the more detailed list of changes.

More reliable recovery from inverted flight

Marc Merlin discovered that on some types of gliders that ArduPilot would not reliably recover from inverted flight. The problem turned out to be the use of the elevator at high bank angles preventing the ailerons from fully recovering attitude. The fix in this release prevent excessive elevator use when the aircraft is beyond LIM_ROLL_CD. This should help a lot for people using ArduPilot as a recovery system for manual FPV flight.

Automatic IC engine support

ArduPilot has supported internal combustion engines for a long time, but until now the pilot has had to control the ignition and starter manually using transmitter pass throughs. A new “ICE” module in ArduPilot now allows for fully automatic internal combustion engine support.

Coupled with an RPM sensor you can setup your aircraft to automatically control the ignition and starter motor, allowing for one touch start of the motor on the ground and automatic restart of the motor in flight if needed.

The IC engine support is also integrated into the quadplane code, allowing for automatic engine start at a specified altitude above the ground. This is useful for tractor engine quadplanes where the propeller could strike the ground on takeoff. The engine can also be automatically stopped in the final stage of a quadplane landing.

Q_ASSIST_ANGLE for stall recovery

Another new quadplane feature is automatic recovery from fixed wing stall. Previously the VTOL motors would only provide assistance in fixed wing modes when the aircraft airspeed dropped below Q_ASSIST_SPEED. Some stalls can occur with higher airspeed however, and this can result in the aircraft losing attitude control without triggering a Q_ASSIST_SPEED recovery. A new parameter Q_ASSIST_ANGLE allows for automatic assistance when attitude control is lost, triggering when the attitude goes outside the defined roll and pitch limits and is more than Q_ASSIST_ANGLE degrees from the desired attitude. Many thanks to Iskess for the suggestion and good discussion around this feature.

Pixhawk2 heated IMU support

This release adds support for the IMU heater in the upcoming Pixhawk2, allowing for more stable IMU temperatures. The Pixhawk2 is automatically detected and the heater enabled at boot, with the target IMU temperature controllable via BRD_IMU_TARGTEMP.

Using an IMU heater should improve IMU stability in environments with significant temperature changes.

PH2SLIM Support

This release adds support for the PH2SLIM variant of the Pixhawk2, which is a Pixhawk2 cube without the isolated sensor top board. This makes for a very compact autopilot for small aircraft. To enable PH2SLIM support set the BRD_TYPE parameter to 6 using a GCS connected on USB.

AP_Module Support

This is the first release of ArduPilot with loadable module support for Linux based boards. The AP_Module system allows for externally compiled modules to access sensor data from ArduPilot controlled sensors. The initial AP_Module support is aimed at vendors integrating high-rate digital image stabilisation using IMU data, but it is expected this will be expanded to other use cases in future releases.

Parrot Disco Support

This release adds support for the Parrot C.H.U.C.K autopilot in the new Disco airframe. The Disco is a very lightweight flying wing with a nicely integrated Linux based autopilot. The Disco flies very nicely with ArduPilot, bringing the full set of mission capabilities of ArduPilot to this airframe.

Major VRBrain Support Update

This release includes a major merge of support for the VRBrain family of autopilots. Many thanks to the great work by Luke Mike in putting together this merge!

Much Faster Boot Time

Boot times on Pixhawk are now much faster due to a restructuring of the driver startup code, with slow starting drivers not started unless they are enabled with the appropriate parameters. The restructuring also allows for support of a wide variety of board types, including the PH2SLIM above.

This release includes many other updates right across the flight stack, including several new features. Some of the changes include:

  • improved quadplane auto-landing
  • limit roll and pitch by Q_ANGLE_MAX in Q modes
  • improved ADSB avoidance and MAVLink streaming
  • smoother throttle control on fixed-wing to VTOL transition
  • removed “demo servos” movement on boot
  • fixed a problem with spurious throttle output during boot (thanks
  • to Marco for finding this)
  • support MAVLink SET_ATTITUDE_TARGET message
  • log all rally points on startup
  • fixed use of stick mixing for rudder with STICK_MIXING=0
  • fixed incorrect tuning warnings when vtol not active
  • support MAVLink based external GPS device
  • support LED_CONTROL MAVLink message
  • prevent baro update while disarmed for large height change
  • support PLAY_TUNE MAVLink message
  • added AP_Button support for remote button input reporting
  • support Ping2020 ADSB transceiver
  • fixed disarm by rudder in quadplanes
  • support 16 channel SERVO_OUTPUT_RAW in MAVLink2
  • added automatic internal combustion engine support
  • support DO_ENGINE_CONTROL MAVLink message
  • added ground throttle suppression for quadplanes
  • added MAVLink reporting of logging subsystem health
  • prevent motor startup on reboot in quadplanes
  • added quadplane support for Advanced Failsafe
  • added support for a 2nd throttle channel
  • fixed bug in crash detection during auto-land flare
  • lowered is_flying groundspeed threshold to 1.5m/s
  • added support for new FrSky telemetry protocol varient
  • added support for fence auto-enable on takeoff in quadplanes
  • added Q_ASSIST_ANGLE for using quadplane to catch stalls in fixed wing flight
  • added BRD_SAFETY_MASK to allow for channel movement for selected channels with safety on
  • numerous improvements to multicopter stability control for quadplanes
  • support X-Plane10 as SITL backend
  • lots of HAL_Linux improvements to bus and thread handling
  • fixed problem with elevator use at high roll angles that could
  • prevent attitude recovery from inverted flight
  • improved yaw handling in EKF2 near ground
  • added IMU heater support on Pixhawk2
  • allow for faster accel bias learning in EKF2
  • fixed in-flight yaw reset bug in EKF2
  • added AP_Module support for loadable modules
  • support Disco airframe from Parrot
  • use full throttle in initial takeoff in TECS
  • added NTF_LED_OVERRIDE support
  • added terrain based simulation in SITL
  • merged support for wide range of VRBrain boards
  • added support for PH2SLIM and PHMINI boards with BRD_TYPE
  • greatly reduced boot time on Pixhawk and similar boards
  • fixed magic check for signing key in MAVLink2
  • fixed averaging of gyros for EKF2 gyro bias estimate

Many thanks to the many people who have contributed to this release, and happy flying!

1 Like

Thank you Tridge and team for all the great work. Looking forward to testing it and using it at the OBC!

Out of interest I as wondering if the RTL takeoff when armed behaviour has changed now and if you could us how to control the new Mavlink LED_CONTROL, AP_BUTTON and PLAY_TUNE functions? Are these for the OBC requirements for buttons and switches?

Regards

it just is more careful to not trigger a takeoff when you are sitting on the ground and accidentally cause a failsafe

they were indeed added for the OBC. They are only available with MAVLink2. Do you want to know how to use them from MAVProxy, or from MissionPlanner or some other GCS?
You can see how we are using them here:

Thanks for the reply Tridge.

With the RTL takeoff it was doing this without failsafe being triggered, and would happen when one cycled through the APM modes on the TX. If armed on the ground it takes off by selecting RTL on the TX/GCS. But I think there has been some changes to is_flying logic which will probably help stop this from happening?

Whenever you have the time a MAVproxy instruction set for the new functions would be welcome. Thank you.

We completed a 55km flight on 3.7 today, before it got too dark and we had to land, with more flights planned for tomorrow. We’re looking to do a +100km on our sub 2kg airframe. (hopefully ;-))

Thanks for all of your continued hard work devs! Lots of good new features.

I gave it a quick run this arvo and everything looks good in terms of the new stuff!

Unfortunately though I still have a problem with my Throttle / Pitch pulsing issue. I can’t trust my plane when the servo is twitching and the motors and ESCs are constantly reving up and down.

Reward for anyone who can solve it. Just graph Pitch and throttle out and you’ll see the issue:

I wish someone could at least point me in the right direction!

@Glen, I’m sorry I didn’t get to look at that issue for 3.7.0. I will try to get to it soon!

Thanks Tridge! I know how hard you guys work on this stuff so don’t take my issue too negatively. APM:Plane just keeps getting better and better because of you guys so keep up the great work :slight_smile:

Thanks @tridge, I appreciate the fix very much.

How come theirs no twin-engine support instead of Y cable on the throttle i like to have it on its own Rc in channel

You can use a 2nd channel for your motor. For example, if you want channel 7 to be a 2nd motor output then set RC7_FUNCTION=70
See http://ardupilot.org/plane/docs/parameters.html#rc7-function-servo-out-function
This is a new feature in 3.7.0

sorry my bad i was reading the wiki and its not listed there in plane when i look in mission planer RC7_FUNCTION=70 was not there i just did an update mission planer guess what its there now

Just had a thought with the issue I’m still facing. I’m using very responsive multirotor type escs with BLHeli, dedicated gate drivers and hard breaking on my plane. It’s also a twin tractor prop with a good power to weight ratio.

Is it possible that the throttle response is too quick to accelerate and decelerate and the osscilations are caused by the throttle response demand loop being too sensitive. Is there a PID loop that can be tuned for the throttle output?

@Glen there are many throttle slew options. Check http://ardupilot.org/plane/docs/parameters.html for:
TKOFF_THR_SLEW - during takeoff
THR_SLEWRATE - during normal flight
LAND_THR_SLEW - during landing

@MagicRuB Slew is only about changing the rate of throttle change per second as I understand it. I’m thinking my problem might be caused by the AP requesting a 5% change for instance and the plane surging forwards too fast because the prop spins up / slows down very quickly. Is it not possible that the autopilot is getting more acceleration or deceleration than expected while trying to maintain a particular airspeed with throttle management?

reducing slew will reduce the feedback agility, effectively adding delay to the system. Slew is intended to protect the battery and motor from physical harm by over exerting and also to reduce roll by adding a high amount of torque to the system. Perhaps we’re talking about different things?

If you’re asking about modifying the control system to reduce demand, then you would want to take a look at all the TECS params, starting with TECS_CLMB_MAX

@MagicRuB Thanks for your response. Do you think it could be caused by the climb max being too high for the airframe?

I have reflashed and re-tuned numerous times both manually and with autotune as a basis as well. I’ve also swapped all of the hardware with the exception of the pixhawk and the ESCs to try and cure the issue. Do you mind having a look at one of my logs and seeing if there’s anything you can put it down to? It usually only occurs in cruise mode and it seems to depend what throttle position I have (or what demanded airspeed I have, since throttle nudge is on) If I change the throttle up and down enough I eventually can get a spot where the throttle and pitch respond as predicted:

7.5 minute mark: https://www.dropbox.com/s/4vs6tvkrr7h8gb1/8.BIN?dl=0

17.5 minute mark: https://www.dropbox.com/s/hw6y8csr3jmkib8/7.BIN?dl=0

It’s definitely TECS related as it presents as an oscillation on the pitch and the throttle (height control).

You may want to look at TECS_TIME_CONST too. That is the parameter that determines how quickly TECS tries to correct a airspeed or altitude error. If you are getting too rapid surges for your taste than increasing TECS_TIME_CONST will slow things down.

@Glen Thanks for posting the logs. However, do you mind posting your help questions on a new discuss server thread instead of on the 3.7.0 release announcement? It will get more visibility and I, or Tridge, or someone form the community can take a look at your logs to help diagnose your tuning issues.

In the code I can see that it supports RMP sensor. It appears that the RMP sensor outputs RPM as PWM. I was wondering what is the sensor which is being used to measure RPM. I am trying to build one using Hall effect sensor and arduino mini. If I can find a ready made one then I do not have to build one.

can’t get the RPM sensor to work… I set all the relays to -1, brd_pwm count to 0, still nothing rpm1=0 even if aileron out is connected to it…