Plane 4.0 release

maybe someone can now tell me where I can shoot a second battery voltage?

I need a second battery indicator in the osd

For example (current sensor is Allegro ACS758LCB-100B with voltage divider to 3,3 V):
Watch my video only in Russian language:

Maybe my video can be useful for you:

It looks like the maximum number of waypoints have been reduced with Plane 4.0 from the previously known 724. We just run into this as we upgraded our planes from 3.9 to the most recent one and uploaded the same mission what we flew 3 months ago. It gave an error now as it exceeded the max number. Anybody aware of the new limit of waypoints?

ahh, that will be the change for CAN DNA storage. It should be 656 waypoints now.
We intend to increase this again in the future using the ability to use the extra memory available on new boards, plus the ability to overflow to microSD. My apologies for not including this in the release notes.

Dear @tridge ! Thanks a lot for the quick response. I was looking at the code and started to wonder if getting rid of the rally/fence points would do us any good, but I would rather stick with the main branch. We highly hope you are able to utilize the new boards with Cortex®-M7 processor so you should have plenty of space to expand. In the meantime we will just upload the new waypoints in a holding pattern in air.

I’m delighted to announce the first beta of Plane 4.0.6 has been released. This is a major release with a significant number of new features and bug fixes. You should read the list of changes and the information below carefully.

  • changed LED scripting API to allow more than 32 LEDs on a pin
  • added support for ProfiLED LEDs
  • added u-blox GPS moving baseline u-blox auto-configuration
  • fixed handling of GPS antenna positions on EKF GPS switch
  • changed default USB IDs to new ArduPilot specific IDs
  • fixed bug in handling trim for RC control of camera mounts
  • added LGR_OPTIONS bits to control landing gear behaviour on takeoff/landing
  • improved mavlink streaming output control to better allocate time to each channel
  • fixed send of mavlink PARAM_VALUE on set of a readonly parameter
  • fixed mag variance reporting in EKF_STATUS_REPORT mavlink message
  • fixed time wrap bug in BMP085 barometer driver
  • fixed buffer overflow in ST24 RC input driver
  • fixed EKF usage of WMM tables when user has specified a specific declination
  • fixed bug in AP_Terrain on-disk format
  • added script for offline generation of terrain data
  • severel improvements to smbus battery drivers
  • fixed a race condition in parameter storage on ChibiOS
  • fixed use of zero GNSS timestamp in UAVCAN GPS driver
  • improved GCS messages during bootloader flash
  • fixed CS pin in bootloader that could corrupt FRAM on some boards
  • added GPS yaw to MAVLink GPS_RAW_INT message
  • added Hott telemetry support
  • added FRSky FPort support
  • fixed bug in CAN clock and queue handling on H7 based boards
  • added support for BRD_ALT_CONFIG for alternative hardware configs on several boards
  • added new boards CUAV-Nora, CUAV-X7, MatekH743, R9Pilot, mRoNexus
  • improved reporting of internal errors to GCS
  • fixed recursion bug in tonealarm player
  • fixed flaperon SERVO_AUTO_TRIM behaviour
  • added option to compensate forward throttle for battery voltage
  • added compensation in VTOL gains for pressure altitude
  • switched to new more flexible compass ordering system
  • fixed forcing of safety off on IOMCU reset
  • increased maximum compass scale factor to 1.4
  • added RTL_CLIMB_MIN parameter for initial climb in RTL

The key changes to existing behaviour to watch out for in this update


ArduPilot has now switched to it’s own USB IDs for all boards. For most users this won’t cause any change, except they may notice the drop down list of devices in MissionPlanner will have the ArduPilot flight controllers labelled more usefully as “ArduPilot” instead of just “STM32”. If you hit issues on windows please try reinstalling the device drivers from this URL:


A bug fix in the format ArduPilot uses to store terrain data means that your flight controller will need to re-download the terrain data onto the sdcard via your GCS. If you fly without a GCS and you use terrain data then please re-download the terrain data you need by setting up a mission when you have internet access and allowing your flight controller to request terrain data from your GCS.

Pressure Altitude Compensation

This release adds in the missing hook for the VTOL motor controller on a quadplane to compensate the VTOL gains using your pressure altitude. For most people this will not have a noticible effect, but some users that have tuned their aircraft for high locations may notice a tuning change.

Compass Ordering

The new compass ordering system in this release gives a lot more
flexibility and should preseve existing configurations and calibrations. If you hit issues then please have a look at the new compass ordering user interface in recent beta releases of MissionPlanner.

Many thanks to everyone who contributed to and tested this release!

Please report test flights here with logs, both good and bad flights.

Happy flying!


Any fix for tkoff mode ?

No changes in takeoff for beta1. I have added the change to ensure it is flying for more than 10s before starting the circle ready for beta2.
Are there any other takeoff mode issues I should know about?

Only a short but good 10 minute flight with Autostart + FBWA, everything worked perfectly (including the thermals :wink: ). There is the log file:

Many thanks to Tridge and everyone who contributed.


Thanks Rolf, much appreciated!

RTL_CLIMB_MIN is ignored if craft is in any quadmode, also if within RTL radius, where it should just got directly to QRTL?
…Just checking.
Nice feature BTW Andrews. Thank you.

right, it is fixed wing only and disabled by default anyway. It is for FPV pilots really.

Beta 4.06 on Matek F765 in a MiniTalon.
Flew a 15 mile loop which took 23 minutes. Used terrain following up and over a butte in cruz mode - no issues. Used the terrain tiles I downloaded with the python script. Calibrated and used a new airspeed sensor - worked good. Tossed the MT with auto takeoff followed with just a rally point while I got ready to fly manually in FBWA - all good. Downloaded log files and all looks great. Did get a RTL after I flew to low down a gully and RSSI dropped to zero. Circle followed by RTL kicked in and brought the MT back up to height and the MT turned to my rally point. Flew home with cruz and fbwa and all is good.

Thanks Don, much appreciated!

I have a issue with a PixHawk 2.4.8 board.
After I upload the ArduPlane V4.06beta1 the LED indicator (4 color LED) is not working anymore.
I reinstall the previous stable version but not change. It also doesn´t matter if I choose Pixhawk1 or FMUV3.
All functions on the board seems ok - just the LED is off. Connection to the mission planer is also working fine.
The board has a STM32F426VIT6 and a 32F100 CPU. So it is a ARM Cortex M4 with 2048kB RAM.
Would be nice to get the LED back working.
Thanks, Markus

Hi, would you recommed using BLHeli escs for a twin motor fixed wing with Arduplane? I didn’t find much information or experiences on this and if there are any disadvantages on using BLHEli escs instead of airplane ones.


They work well for me!

I’ve been using a T-Motor F45A 3-6S BLHeli_32 ESC for about 3 months now in a Mini-Talon - no issues and saves a lot of weight.

Thanks @Naterater and @lazydude for your responses. Do you add any capacitor to the BLHeli escs?