Plane 4.2 stable release

Hi tridge,the plane become unstable in FWBA mode in case of losing GPS. I once lost GPS during a flight, and the plane became very unstable and difficult to overcontrol. I switched back to manual and kept flying until the GPS was restored and the plane was stable again。 But unfortunately, there’s no flight log。I set the Tecs_synsthetic speed=1。I don’t know if this is the cause of the flight instability, normally FWBA mode does not require GPS signal , Is there a logical hole in this?@tridge

Could someone provide a parameter file where the camera trigger works correctly? so i can compare it with mine and see what could be wrong.

1 Like

I solve it, I don’t know exactly why, but only a single port accepted to be activated as a trigger for the camera, which was AUX6, all the other AUX or MAIN did not accept it.

The configuration I used was simple,

CAM_TRIGG_TYPE = 1 (Relay)
RELAY_PIN = 55
SERVO14_FUNCTION = -1 (GPIO)


I’ve just released plane 4.2.3beta1. This is a minor release, but it includes some significant changes. The changes are:

  • allow INA2xx battery to init after startup
  • fixed healthy check on battery monitors to check all enabled monitors
  • added Pixhawk6C and Pixhawk6X support
  • fixed alighment of QRTL start in fixed wing circle landing approach
  • added Foxeer Reaper F745 support
  • added MFE PixSurveyA1 support
  • fixed combination of waypoint passby with acceptance distance
  • cut throttle on ICE stop when armed
  • added ICE option for starting when disarmed
  • zero VFWD integrator on ICE override in quadplanes
  • don’t failsafe when in fixed wing landing sequence with RTL_AUTOLAND
  • improved handling of overshoot in VTOL landing
  • added arming check for VTOL_LAND too close to previous WP
  • improved choice of target airspeed in VTOL landing approach
  • improved ICM42xxx filter settings
  • allow for faster sample rates on ICM42xxx

VTOL Landing Changes
The quadplane changes are focussed on two issues that have come up for users. The first is overshoot in VTOL landing. With previous releases if you had a significant overshoot of the landing point (for example if you had a VTOL_LAND very close to the previous waypoint) then the VTOL landing code would handle it very badly and actually fly away from the landing point for some time until the position controller unwound its buildup of target acceleration. The new code has special overshoot handling for this case. You will get a “VTOL Overshoot” message on the GCS and the aircraft will slow down then yaw around to face the landing point before proceeding back to the landing point at a speed limit of Q_WP_SPEED. It will yaw to keep the nose into the wind while moving back to the landing point.
The second key change is the choice of when to start VTOL control on the landing approach. The new code adds some more margin to start VTOL control sooner, which makes overshoot less likely.
The beta also adds a new arming check to ensure the distance from the previous waypoint to a VTOL_LAND is at least 75% of the calculated distance needed for a smooth stop (based on Q_TRANS_DECEL). This is to prevent users having a set of waypoints which lead to a large overshoot.
The final VTOL landing change is to suppress failsafes while you are in a landing sequence with DO_LAND_START. So once the series of waypoints following a DO_LAND_START has started any RC or GCS failsafes are ignored, allowing the landing to continue without forcing a go-around.
VTOL Land Airspeed
This release also changes the airspeed used for the approach to a VTOL landing if you have not specified a TECS_LAND_ARSPD. The airspeed used will be half way between ARSPD_FBW_MIN and TRIM_ARSPD_CM, so that the aircraft does slow down during the VTOL landing approach. Setting a TECS_LAND_ARSPD overrides this with a specific airspeed target.
Fixed Wing Approach Fix
The VTOL land option which uses a fixed wing approach followed by circling the landing point to estimate the wind then turning towards landing into the wind has been fixed to handle the case where the circling radius is smaller than the distance needed for the VTOL landing. We now ensure that we do turn towards the landing point before we transition, so we don’t end up trying to transition while at 90 degrees to the landing direction.
ICE Changes
The second significant set of changes is for ICE setups, where you control an internal combustion engine.
The first ICE change is to ensure you have zero throttle when you disable the ICE subsystem with the ICE control RC channel while armed. Previously we relied on the user having an ignition cut to kill the engine, and the throttle could still be active due to integrator buildup. The change is to help users without an ignition control channel, such as EFI systems that use zero throttle to kill the engine.
The second ICE change is a new ICE_OPTIONS bit to allow starting of the engine while disarmed in MANUAL mode. This can make for safer startup procedures as it ensures that VTOL motors cannot start even if you accidentally change flight modes or get a failsafe while waiting for the engine to startup.
ICM42xxx Filter Changes
The filter configuration on the ICM42xxx Invensense IMUs has been improved to better match the filtering we use on other IMUs. I’d be interested in feedback from users flying with these IMUs if you notice any issues with the new settings. It should be a significant improvement.
Happy flying!

5 Likes

Hey,

I have a Quadplane VTOL with 4.2.2 Firmware and I have been facing an issue when I try to land. Plane basically begins airbraking within the range I roughly calculate with Q_TRANS_DECEL but after airbraking for some time, one of the motors stops producing thrust (for one time motor stopped fully, the other time I could observe that motor was at least spinning after the fall). I did not have an issue like this with 4.1.7 firmware and I have flown it many times. First time it was the front left motor and for the second time it was front right motor. I checked electronics and wiring seems like it does not have any problem. It looks like ESC de-sync issue from the logs. My logs are nearly the same with @Mark_Rosser just like his motor PWM outputs mine have the same changes. I have seen that Mark has a grounding issue but seems like mine is not a grounding issue.

Can anyone give me an explanation or clarify what is happening after changing to 4.1.7 to 4.2.2 that triggers to stop the motor.


I’ve just released plane 4.2.3beta2. This is a minor update over 4.2.3beta1. Changes since 4.2.3beta1 are:

  • OpenDroneID support
  • fixed notch filtering ordering issue on loss of RPM source
  • fixed Lutan EFI update serial flood
  • fixed --upload to work on WSL2

More information on the OpenDroneID support will be published later today.
Happy flying!

2 Likes

Hi Trkv,
My fault was a faulty ESC. Nothing to do with the firmware upgrade. After repairing the ESC it works fine in a flight test. Follow tridge’s advice and see if you can duplicate the fault on the ground with the motor test. Upgrade to the latest firmware 4.2.3 lots of trans and landing changes ( see Tridge’s release notes above )

Hey Mark,

I tried Tridge’s advice but I could not duplicate the issue, motors and ESCs both worked without any problem. @tridge do you have any idea what might be the problem?

@Trkv start by posting a link to a log

I have tried ArduPlane 4.2.2 with CubeOrange with 2 different VTOL planes. Both had a problem during landing. For once it was front left motor which stopped and for the other it was front right.

Here are my logs,

Front Right Failure:
https://drive.google.com/file/d/1nie1ACMuYf4ql69mg49OKAZD3DeVGDDu/view?usp=sharing

Front Left Failure:
https://drive.google.com/file/d/1c_mO40yqgyp18QHezxRo8C8APWMDB278/view?usp=sharing

As pixhawk 4 is stopped (I use them in 2 different gliders), I would like to purchase a pixhawk 6.
My configuration is : 3.7 m glider (6 servos+prop)
Not professional use

Do you advise pixhawk 6c or 6x ?

Thanks
Adolfo

Hello.
As shown in the image below, when I try to upload Plane4.2.3beta2 to Pixhawk6X, I get the error “Error: Firmware not suitable for this board fw:10053 - board53”.
How can this be resolved?
I would be happy if you could tell me.

Best regards.

error1

@tridge
Sorry for the repeated question.
When I tried to upload the ArduPlane 4.2.3beta2 firmware that I built from github master to CubeOrange, I got the error “ERROR: Firmware not suitable for this board fw: 10140 - board 140”.
Also, even if I upload ArduPlane 4.2.3beta2 from the beta version of Mission Planner as shown in the image below, the same error is returned.
How can this be resolved?
I would appreciate it if you could tell me.
Thank you.
error2

the problem is you are using the “ODID” firmwares, these are OpenDroneID firmwares with board IDs that deliberately don’t match the normal board IDs. They are examples for US vendors preparing for the RemoteID requirement for vehicles sold after 16th September
Please use the firmwares without ODID in the name

1 Like


I’ve just released plane 4.2.3beta3. This is a minor stable release with a few new features and bug fixes. The changes from beta2 are:

  • OpenDroneID improvements
  • added --enable-opendroneid configure option
  • added --enable-check-firmware configure option
  • reverted notch filter changes from beta3 due to issue on some aircraft
  • enable OSD menus on KakuteH7
  • added prearm checks for rangefinder pin conflicts
  • added diagnostics for scurve internal error
  • allow absolute paths for linux boards in param defaults
  • fixed AIRBRAKE rc option warning

I expect to release 4.2.3 within the next few days. Test reports would be most welcome!

1 Like

@amilcarlucas Pixhawk6X is fully supported in the 4.2.3beta releases

Thanks tridge. In the future I’ll know better

@tridge the 4.2.3 beta 1 shows BATT_MONITOR > 24 as Fuel Level Analog. But the complete parameter list does not include the documentation for the same. could you please shed some light on it.

TIA


I have just released plane stable 4.2.3. This is likely to be the last stable release before we release the first 4.3.0beta.
The changes since 4.2.2 are:

  • added OpenDroneID support
  • enable OSD menus on KakuteH7
  • added prearm checks for rangefinder pin conflicts
  • added diagnostics for scurve internal error
  • allow absolute paths for linux boards in param defaults
  • fixed AIRBRAKE rc option warning
  • fixed notch filtering ordering issue on loss of RPM source
  • fixed Lutan EFI update serial flood
  • fixed --upload to work on WSL2
  • allow INA2xx battery to init after startup
  • fixed healthy check on battery monitors to check all enabled monitors
  • added Pixhawk6C and Pixhawk6X support
  • fixed alignment of QRTL start in fixed wing circle landing approach
  • added Foxeer Reaper F745 support
  • added MFE PixSurveyA1 support
  • fixed combination of waypoint passby with acceptance distance
  • cut throttle on ICE stop when armed
  • added ICE option for starting when disarmed
  • zero VFWD integrator on ICE override in quadplanes
  • don’t failsafe when in fixed wing landing sequence with RTL_AUTOLAND
  • improved handling of overshoot in VTOL landing
  • improved choice of target airspeed in VTOL landing approach
  • improved ICM42xxx filter settings
  • allow for faster sample rates on ICM42xxx

Many thanks to everyone who tested the beta releases.

Happy flying!

9 Likes

I recently has some RC decoding issues that were fixed by a power-cycle. Autopilot was a CUAV V5+ running Plane 4.2.3. RC receiver is an RX6R connected via SBUS and to a serial port for yaapu telemetry.

Tlog only, since I (thankfully) noticed the issue before arming and have LOG_DISARMED =0. Issues start at about 11% when the RC transmitter is turned on. Much of the time is spend with only the mode switch (ch5) being moved and sticks neutral, yet channels 1-4 are at fixed non-trim values. Channel 5 should get all the way up to the 1800s (mode 6) as I sweep the mode switch while debugging, but it doesn’t. The channel output percentage on the Taranis moved as it should.

After a reboot, everything worked normally. This flight is the second half of the attached tlog.

I suspect I had this happen once before to a different, but nominally identical aircraft several weeks ago running 4.1.7, but I dismissed it as a one-off and don’t have the log. In this case I scrubbed the flight once I noticed the mode changes. This suggests it’s not a hardware failure problem.

1 Like