Plane 4.0 release

multiple flight hours with https://github.com/ArduPilot/ardupilot/pull/14203 and https://github.com/ArduPilot/ardupilot/pull/14299 added with good results. thanks @andyp1per for a bunch of great additions!

basti

Hey @tridge @rmackay9
Will Arducopter get THR_FAILSAFE=2?
It would be great for copter BVLOS tests.

copter has a nice FS_OPTIONS parameter. I’m thinking in future of adopting FS_OPTIONS for plane, possibly with some extra bits defined


The ArduPilot development team is proud to announce the release of plane 4.0.6 stable. This is a significant release with a lot of changes, so please read the change summary 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
  • fixed disable of throttle nudge during a RC failsafe
  • added support for a wider range of DLVR airspeed sensors
  • fixed RC input processing for out of range RC channels
  • added THR_FAILSAFE=2 option for flying BVLOS with only GCS failsafes enabled
  • fixed reordering of compasses on boot based on compass priorities
  • fixed use of minimum accuracy for GPS data in EKF2 and EKF3, fixing an issue with RTK GPS modules that report overly optimistic accuracy values
  • fixed handling of RC_OPTION bit for disabling receiver failsafe handling
  • fixed LOITER_TO_ALT with terrain altitude target
  • fixed an issue with swapping UAVCAN compasses and calibration
  • fixed use of VTOL quadplane missions (where the plane flies as a multi-rotor for auto waypoints)
  • fixed legacy parsing of some lightware i2c lidars when beyond max range
  • fixed RTL_AUTOLAND with MIS_RESTART=1
  • enable more compasses on low flash boards
  • HAL erase storage fix for flash storage boards
  • prevent jump to circle mode in TAKEOFF if flying for less than 10s
  • fixed handling of out of range on LightwareI2C Lidar
  • fixed init of HoTT telemetry
  • added support for mRo Pixracer Pro, Holybro Pix32v5
  • added arming check for terrain data healthy if needed
  • increased monitor thread size to 768
  • fixed IMU fast sampling on F35Lightning board

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

USB IDs

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:
https://firmware.ardupilot.org/Tools/MissionPlanner/driver.msi

Terrain

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.

THR_FAILSAFE=2

For people flying before visual range (with appropriate
authorisations) there is a new option which allows for safer
operation. By setting THR_FAILSAFE=2 you can setup the R/C failsafe so
that R/C input will stop being used when one of the receiver failsafe
conditions is met, while not triggering any failsafe actions. This is
a significant improvement over setting THR_FAILSAFE=0 as it prevents
the receiver inputs being used for stick mixing and other inputs that
would be inappropriate when in receiver failsafe.

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

Happy flying!

5 Likes

Now that’s a novel

Thanks’ to all who worked on it
now i have something to do in lockdown :+1:

Stable 4.06 doesn’t appear to be available in MP?

Just getting ready for a flight tomorrow. Currently flying 4.06beta5.

Thanks!

its there on my end

Is that a beta of MP?

i don’t think so but it may be i did read some where to up to the latest

My MP is 1.3.7530.26934 and if I check for updates it only offers a beta update that fails “Error getting Parameter Information” so I canceled it. I guess I’ll wait a day or two. Was headed out flying tomorrow morning so hoped to get this loaded.

if your using windows 10 you need to run it as ADMIN to update it

Interesting - started it with admin and mp updated to 1.3.7555.20712 but still only offers 4.05 stable and beta up to 4.06b5.

Maybe I’ll check the github repository… Yep 4.06 stable is there but for some reason it won’t show in my MP. It uploaded fine manually but still odd that it doesn’t show in MP for me.

Hi.
Thanks for great work and detailes information. I had Matek F405 wing board and R9mm frsky receiver. Till now i cant the telemetry work through inverted F.port of R9mm (on 4.0.5 version) to TX2 uart pad on fc with frsky passthrough protocol(serial protocol 10) Everybode recommended an inverter for fport in case of f4 boards. Will this release solve this issue so can i use R9mm receiver inverted Fport without diode and ttl converter to get telemetry.?!
What is the right setup: is serial2 prtocol10 or 23 ? serial_option 0 or 7?
Many thanks

I could not get F-Port working with the latest FrSky firmware. I think it’s a bug because it works with the older version. Cross posted here: FrSky FPort support - testers wanted

I downloaded the latest version of ArduPlane today to a Kakute F7 but now I cannot control the flaps from the transmitter. I cannot find how to control it anymore.
My fault or code change?

Mr Anders W
Sweden

can you send me a tlog showing you trying to move the flaps on the ground? Or a bin log with LOG_DISARMED=1

Hi Tridge

Nice to hear from you.
If I am correct there was something like “FLAP_RC_CH”. Now there is not.
I have no clue how to connect an RC channel to the control the flaps.
The RC input is working.
The Flaps are working in Setup -> Servos and if I click Reverse they move as they should

I’m running the code on a Kakute F7. The Flaps on CH 5 and Dshot on Ch 6.
Motor, and all other servos are working perfectly but I cannot control the flaps.

Anders

in 4.0 there is a parameter FLAP_IN_CHANNEL that you are probably referring to.
For 4.1 (in development now) this has been replaced with a RCn_OPTION “FLAP” (value 208). So you RC7_OPTION=208 to make flap input come from channel 7.


I’ve just released plane stable 4.0.7beta1. This is a minor release with some important bug fixes against 4.0.6.

The changes are:

  • Fixed F32Lightening board IMU fast sampling issue
  • fixed issue with EKF2 and EKF3 with use of high accuracy GPS modules. This is important for anyone flying with a RTK GPS
  • Fixed KakuteF7 DShot glitch issue
  • Fixes issue with checking for valid RC input in ICE disable channel
  • fixed an interrupt flood issue with any sensor that uses interrupt timing measurement, such as RPM sensors.
  • Modified RM3100 driver to problem all 4 possible I2C addresses
  • Fixed UDP RC input on Linux boards to accept up to 16 RC inputs on UDP

The most critical fix in the above list is the ISR flood issue.

ISR Flood Issue

The ISR flood issue happens when a misbehaving external sensor (such as an RPM sensor for a petrol motor) starts providing pulses faster than the flight controller can process them. If this happens then the CPU can be overloaded in the interrupt handling for the sensor and stop flying the vehicle. The level of interrupt rate needed to cause this issue is around 500k interrupts per second, so to be safe we have added a limit of 100k interrupts per second. If a single interrupt source produces more than 10k interrupts in a single 0.1 second period then we disable that interrupt source, print a warning to the user and raise an internal error.

Happy flying!

2 Likes