Plane 4.2 stable release

thanks Colin.
I checked the logs, and I’m seeing zero current (under 0.001 amps) with both your 4.2.0 log and your 4.1.7 log.
I also loaded the parameters from your 4.2.0 log onto a CubeOrange here with a standard yellow power brick and it did read current and voltage correctly.
I have reproduced the RSSI issue, and I have a fix here:

I’ll include this fix in 4.2.1
Thanks for reporting the issue!

updated firmware with RSSI fix here:
http://uav.tridgell.net/tmp/plane-CubeOrange-4.2.0-rssi-fix.apj
please test

Any thoughts on my previous error report a few posts back? After booting up it gives some cheerful sounding beeps then just sits there emitting a constant tone.

sorry for the slow reply.
I flew a plane with a MatekH743-Wing (v1) yesterday with no issue on 4.2.0.
I just loaded a H743-Wing v2 now via STM32CubeProgrammer from arduplane_with_bl.hex. Interestingly, on the first boot it did as you described, beeped and didn’t show up a port to connect to. Power cycled it again and it was fine.
One thing about the MatekH743-Wing is it stores parameters in the last 2 sectors of flash, so updating via DFU doesn’t wipe parameters. Can you try resetting parameters first then updating? Do that either by loading 4.1.7 and setting FORMAT_VERSION to 0 or by loading a different vehicle type (eg. copter).

here is some log its working fine the current sensor working as well
this got me beat why this is but if i put stable it stop working

thanks for your time Andrew

https://drive.google.com/file/d/1bzv_gtZ7_-pR2GRWdd1iudJ6PTKOGByZ/view?usp=sharing

1 Like

Thanks Andrew, I’ll give it a try tonight.

Well that was interesting. I set FORMAT_VERSION to 1 while running 4.1.7, then upgraded the firmware via Mission Planner to 4.2. On the first boot it came up fine, so I loaded up my saved parameter file from 4.1.7 and wrote it to the hardware. A few warnings about readonly parameters but so far so good. I then power-cycled the board by unplugging the USB and plugging it back in, and when it started up again it gave the starting-up trill but then got stuck on the last note and just played a continuous tone.

I’ve attached my parameters file in case someone wants to try and figure out what part of it is incompatible with 4.2.
ardupilot_h743_wing_v2_explorer_after_upgrade_4.2.0.param (21.0 KB)


I’ve just released plane 4.2.1beta1. This is a minor release on top of the 4.2 firmware. It has a number of bug fixes and safety improvements. The changes are:

  • fixed a bug in handling wrap in log download when 500 logs are on the microSD card
  • added FlyingMoonF407 and FlyingMoonF427 support
  • fixed RSSI input on the RCIN pin on CubeBlack and CubeOrange
  • fixed update of gyro FFT throttle tracking
  • removed unhealthy reporting on airspeed sensors with negative pressure as this commonly happens on VTOL takeoff
  • improved handling of large LOITER_TURNS mission items, expanding maximum to 2.5km
  • added fuel usage integration on Lutan EFI
  • refuse arming in AUTO when in a landing sequence due to a failsafe
  • account for sprung throttle (from RC_OPTIONS) in throttle suppression code
  • improved safety of in-flight compass learning
  • fixed automatic airspeed ratio calibration for 2nd airspeed sensor
  • increase safety of GUIDED → AUTO takeoff sequence used by QGC
  • added CAN_Dx_UC_ESC_OF parameter for ESC offset for bandwidth efficiency

The most important fixes are related to how QGC (which is often used on modern GCS style transmitters) does automatic takeoff with the “swipe right for takeoff” system. QGC does a sequence of a change to GUIDED mode, then arming, then change to AUTO mode. That sequence is dangerous if the current waypoint is not properly reset to a VTOL
takeoff. To fix this a number of changes were made to ensure that takeoff is done with a valid VTOL takeoff. The changes include handling of failsafe events (such as GCS or RC failsafe) part way through this takeoff sequence. If QRTL or RTL is engaged during this sequence then the vehicle will switch to QLAND.
One of the changes users may notice is the throttle suppression change for sprung throttles. The change is that if you clear the RC_OPTIONS bit “Arming check throttle for 0 input” then we now assume you have a sprung throttle, and the throttle will be at neutral (close to trim, which will should around 1500) when you arm. In that case when you arm in QLOITER or GUIDED mode then the VTOL motors stay at idle until the throttle stick goes above the throttle trim plus the dead zone. This will be most noticeable in QLOITER, as stabilization won’t start until you push up the throttle, whereas previously the motors would have started stabilizing as soon as you arm (as it saw 50% throttle input). The reason for the change is to ensure that when armed in GUIDED mode we don’t immediately go to an “is-flying” state due to raised throttle when you have a sprung throttle.

Happy flying!

5 Likes

after update to 4.2,the battery voltage display wrong,the flight mode can’t not display in message position,the current also can’t update

please tell us what flight controller you are using, and provide a telemetry log of it working with 4.1, and a telemetry log of it not working with 4.2

@Sampson can you try to reproduce this? Have you heard of any issues with 4.2 plane on a MatekH743-Wing2 ?

I don’t remember users reported this with H743-WING V2. In the past, some users reported that the V1 had stuck booting with 3.9/4.0. I haven’t heard much about this in recent one year. I usually do full chip erase before flashing in DFU mode with STM32CubeProg.

TRIDGE ,THE FC is matek F765 WING.the firware go back to 4.17,osd display normal.
2022-05-22 13-16-12,4.2 DJI OSD DO NOT DISPLAY RIGHT.tlog (210.3 KB)
2022-05-22 13-33-37 DJI OSD DISPLAY NORMAL.tlog (162.2 KB)

in both those logs the OSD is disabled as OSD_TYPE=0. For the DJI MSP OSD you must set OSD_TYPE=3
See the documentation here: MSP OSD — Plane documentation


I’ve just released plane 4.2.1 stable. This is a minor release with the following changes since 4.2.1beta1:

  • fixed handling of safety state on boards with no safety switch
  • fixed bug where a false positive could trigger quadplane landing disarm while land repositioning is active

For completeness, here are the changes from beta1 over the 4.2.0 release:

  • fixed a bug in handling wrap in log download when 500 logs are on the microSD card
  • added FlyingMoonF407 and FlyingMoonF427 support
  • fixed RSSI input on the RCIN pin on CubeBlack and CubeOrange
  • fixed update of gyro FFT throttle tracking
  • removed unhealthy reporting on airspeed sensors with negative pressure as this commonly happens on VTOL takeoff
  • improved handling of large LOITER_TURNS mission items, expanding maximum to 2.5km
  • added fuel usage integration on Lutan EFI
  • refuse arming in AUTO when in a landing sequence due to a failsafe
  • account for sprung throttle (from RC_OPTIONS) in throttle suppression code
  • improved safety of in-flight compass learning
  • fixed automatic airspeed ratio calibration for 2nd airspeed sensor
  • increase safety of GUIDED → AUTO takeoff sequence used by QGC
  • added CAN_Dx_UC_ESC_OF parameter for ESC offset for bandwidth efficiency

The most important fixes are related to how QGC (which is often used on modern GCS style transmitters) does automatic takeoff with the “swipe right for takeoff” system. QGC does a sequence of a change to GUIDED mode, then arming, then change to AUTO mode. That sequence is dangerous if the current waypoint is not properly reset to a VTOL takeoff. To fix this a number of changes were made to ensure that takeoff is done with a valid VTOL takeoff. The changes include handling of failsafe events (such as GCS or RC failsafe) part way through this takeoff sequence. If QRTL or RTL is engaged during this sequence then the vehicle will switch to QLAND.

One of the changes users may notice is the throttle suppression change for sprung throttles. The change is that if you clear the RC_OPTIONS bit “Arming check throttle for 0 input” then we now assume you have a sprung throttle, and the throttle will be at neutral (close to trim, which will should around 1500) when you arm. In that case when you arm in QLOITER or GUIDED mode then the VTOL motors stay at idle until the throttle stick goes above the throttle trim plus the dead zone. This will be most noticeable in QLOITER, as stabilization won’t start until you push up the throttle, whereas previously the motors would have started stabilizing as soon as you arm (as it saw 50% throttle input). The reason for the change is to ensure that when armed in GUIDED mode we don’t immediately go to an “is-flying” state due to raised throttle when you have a sprung throttle.

Happy flying!

3 Likes

@tridge, I have successfully tested automatic flaps in mission with SERVOn_FUNCTION,3

But now my flaps/ailerons configuration is crow:

SERVO10_FUNCTION,86
SERVO9_FUNCTION,87
SERVO8_FUNCTION,17
SERVO7_FUNCTION,16

With this setup, is there any chance in this release to activate this crow mix in auto landing?

yes, if your differential spoilers are setup to allow for flaps then it can activate in landing if LAND_FLAP_PERCNT is non-zero.
See Differential Spoilers & Full House Wing — Plane documentation for more info on differential spoiler options

1 Like

I set OSD_TYPE=3, but I don’t know why the record shows OSD_TYPE=0

Did anyone else working with a quadplane have trouble getting the ESCs to work/respond normally after updating to 4.2 from 4.1?

I’ve had one other report of that, and it was caused by Q_M_PWM_MIN and Q_M_PWM_MAX both being set to zero.
Please post a bin log while running a motor test with LOG_DISARMED=1 to help diagnose