Plane 4.2 stable release

For log and photos use this link

can you add a log from 4.0.9 where it is working as you expect?

How to remove "PreArm: In landing sequence’’ option from the arming checklist ?
Is it possible ? because I didn’t find this in pre arm check list param.
Please help me out.

1 Like

Upgraded my VTOL to 4.2.2 from 4.1.7 ( 30 + flights ) first flight after upgrade.
T -Tail 4 x T - Motor U5 & Alpha ESC
take off in Qloiter fine then cruise then loiter couple of turns then Qhover all fine then Qloiter to land, constant ccw yaw, no stick inputs quick decent held position but very fast constant yaw. noticed that motor 1 was at 1300 PWM and motor 2 was at max 1950 PWM throughout the yaw. I have bench tested the motors under load fine. The FC was sending signals to the ccw motors min & max dont have a clue as to why. Can any one help me. Here are the Tlog Data flash log and the VTOL params. The logs are long they start at 68%
Here is the google drive link to the logs and params

Hi Mark,
You definitely lost power to the rear-left motor.
Here are the motor demands:

Here is a motor model of predicted current compared to the actual current draw during the takeoff and initial flight:

you can see that the DC motor model predictor does do a very good job of predicting the current draw on your VTOL motors
and here is the model for the final part where you lose a motor:

you can see the point where it diverges very clearly
and here is the motor model prediction if we subtract off the prediction for the failed motor:

you can see that it does match at times, but is “stuttering”.
What is almost certainly happening is PWM signal corruption. On high motor demand (most likely on rapidly changing demand) you are either getting ground lift or getting switching noise from the ESCs causing signal corruption.
To try and reproduce this on the ground you need to give a sudden motor demand. Strap down the vehicle and use MissionPlanner to do an 80% motor test of one motor for 5 seconds with the propeller on. If the motor stutters at all then you have a signal corruption problem. Correct operation is to go to a constant RPM for 5 seconds.
To fix the issue you can do several possible things:

  • set BRD_PWM_VOLT_SEL to 1 to use 5V signalling on the 8 MAIN outputs of the cube orange. This will give you more signal margin and make the issue less likely
  • set Q_M_SLEW_UP_TIME and Q_M_SLEW_DN_TIME to 0.2, this will slow down the maximum ramp of the motors, which tends to be what causes the issue
  • change your wiring to ensure the PWM signal cables are not running close to either motor power or the 3-phase motor wires
  • shield your wiring
  • switch to CAN ESCs

Hi Tridge,
Thankyou for detailed analysis of my logs. You nailed it, i was able to reproduce the stutter via mission planner 80% motor test 5 out of 6 attempts on rear left motor ( other motors fine ). I tried changing the params you recommended no difference. FYI here is a log of the stutter after param changes. i will have to go through a process of elimination to find out the prob, motor,ESC or wiring. At least i now no what happend.
Cheers Mark

great, thanks for letting me know. Please follow up with what you do to solve the issue.

Hi Tridge,
swapped the motor/esc to the other side of the plane ( different wiring loom ) still stuttering. I have sent link to some photos. the ground signal wire has melted its insulation. and sitting over a big transistor dont know why.
Google Photos
the first photo is how i found it out of its case

hi Mark,
I think this would be worth breaking out as a new topic. Then I’d suggest we ask @Leonardthall to comment on how to fix the grounding issues. The ground wire melting means you’ve got a lot of current flowing on ground.
Start a new topic so we leave the stable 4.2 release topic for it’s main purpose.
Cheers, Tridge

Hi tridge,
I am running the signal ground off the ESC power ground ( foxtech wiring ).?

Google Photos

@tridge Sorry for the late reply… that data is corrected, sir. next time I will send logs.
Thank you

Hi tridge,

I have setup a new topic.
Grounding issues

1 Like

Hi all,
I’ve converted a plane from INAV (more than 50 flights without any issues) to Ardu stable. Quite successfully. However, I’m still an Ardu beginner… and ran into an issue…

-Flux wing
-Matek 405 Wing (no sd card)
-Crossfire 4.10
-Banggood GPS NEO 8M

  • 2 x digital PTK servos

On the bench/outside I had the issue I could not arm due to GPS unhealthy. I had 10 Sats:

15.07.2022 09:46:30 : PreArm: Logging failed
15.07.2022 09:46:30 : PreArm: GPS 1: not healthy
15.07.2022 09:46:29 : PreArm: Logging not started
15.07.2022 09:45:59 : PreArm: Logging failed
15.07.2022 09:45:59 : PreArm: GPS 1: not healthy
15.07.2022 09:45:45 : PreArm: Logging not started
15.07.2022 09:45:36 : AHRS: EKF3 active
15.07.2022 09:45:28 : PreArm: Logging failed
15.07.2022 09:45:28 : PreArm: AHRS: Not healthy
15.07.2022 09:45:25 : PreArm: AHRS: Not healthy
15.07.2022 09:45:13 : AHRS: DCM active
15.07.2022 09:45:09 : AHRS: EKF3 active
15.07.2022 09:45:08 : AHRS: DCM active
15.07.2022 09:43:28 : PreArm: Logging failed
15.07.2022 09:43:28 : PreArm: GPS 1: not healthy
15.07.2022 09:43:22 : PreArm: Logging not started
15.07.2022 09:43:12 : IMU0: fast sampling enabled 8

That was without a SD Card inserted. So I disabled logging:

because actually I don’t need it. So arming was then possible straight away. Yay!

Wing was flying great out of the box on Ardu maiden. When I started Autotune routine the control surface started to freeze randomly not always but after right left/left right procedure sometimes.

I’ve decreased the servo hz from 300 to 50 but still had freezes. (initially I thought the 405Wing BEC was overloaded, but hey we are talking about 2 servos…) Back then it was the third flight. So, I’ve enabled logging again and put a SD card in it and put the servos back to 300hz. Took it for a fourth flight today and no freezes at all. Whatever I do it flys flawless in all modes + Autotune.

Attached by is my latest param from today
Flux_latest2.param (18.5 KB)

I’m not sure if this is worth looking into, but I thought it was quite scary.
Thank you for this great piece of software and that you share it with the community !!!


@tridge, the question in @sibi’s case is whether a missing SD card or switching off logging can lead to a servo freeze?

Doesn’t anyone have an opinion on the problem?

I have a problem with the camera trigger, I use a pixhawk 2.4.8 controller, arduplane 4.2.2, Canon G9 X Mark II camera.

I haven’t used this controller and camera for a long time, but with previous versions of arduplane everything worked correctly, especially the camera trigger, the settings I used were the same as in this tutorial (Index of /copter/docs common-pixhawk-camera-trigger-setup.html).

Now I’m using this equipment again and I’m updating it to the new arduplane 4.2.2 version, but I can’t make it work, the settings I tried were those in the images below.

But I can’t shoot the camera by the command “Trigger Camera NOW”

Can anybody help me?

My parameters
Parametros Drone Horus_-20220801-_1250hr.param|attachment (16.0 KB)

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)

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!