Plane 4.2 beta release

airspeed drops quickly when one motor goes into reverse. TECS responds by adding throttle.

radio failsafes in AUTO don’t affect plane, it keeps flying normally
The ISR flood error is the internal error, yes

Reverse thrust (barely) used in landing here. Although different firmware and autopilot. I don’t have any automated landings of the plane that crashed, although because of the gentle spin, it actually did little damage. I’ll follow up.

unfortunately that is an old firmware. I was hoping to see what the RawRPM field did with reverse thrust, to see if it went negative. This old firmware doesn’t log RawRPM.
Can you do a bench test with some reverse thrust and get a log?
Also, can you try a test where the motors are setup the way way they are setup in the crash, then you disconnect the signal wire from the ESC so the DShot pulses stop. I’d like to know how long the motors keep running for after the pulses stop.

@Naterater can you also tell us what BLHeli32 firmware was on the ESCs and what model of ESC?

Any change of putting TRIM _AUTO back in. SERVO_AUTO_TRIM doesn’t work for me as I have no speed sensor or GPS.

Hi, We are seeing very bad behavior in the flight controller and wonder if there is a fix? Basically we are seeing large ~5 deg pitch changes with large changes in Throttle in VTOL aircraft. I don’t think this problem is limited to Plane Beta 4.2.

Exemplifying this is a Convergence SITL model based on Plane Beta 4.2. Here we are seeing ± 5deg pitch changes with large changes ~ 70% in throttle. Here is the log file of our test, and a picture of the pitch (red), DesPitch (green), and throttle signals (blue):

Log file:

In comparison, the stock mini Convergence, or any quadcopter that comes with Realflight 9.5 does not show any affects of throttle on pitch. Since the flight control algorithm is different. This indicates the effect is being created by the Ardupilot flight control algorithm.

I am developing a large RC controlled tricopter VTOL using Arduplane and we are seeing ~ 5 deg pitch changes with large changes in throttle, making the vehicle very hard to handle and has crashed many times. Here are two videos of the vehicle being tested. The first has PID (a lot more P than I) tuning, and the 2nd has IPD (a lot more I than P):

First test using PID tuning:


Second test using IPD tuning:


Throttle (Blue), Red (Pitch), Green (Despitch)

We would like to find a solution to this problem.

Here is a link to see the vehicle and details about its construction:

I have also developed a CAD model of the vehicle and have it flying in RealFlight 7.5, but it does not use a flight controller and flies very well. The reason is that the vehicle weighs 200 lbs and is the size of a large station wagon, which has high rotational inertia, and large stabilizing gyroscopic effects from the 32in props. The key point is that the pitch does not change with large throttle changes. Here is a link to see the vehicle flying in the simulator:

We are now considering taking out the flight controller because the vehicle is too hard to handle with Throttle causing Pitch changes.

I’ve just released plane 4.2.0beta6. This is the 6th (and hopefully final!) beta of the 4.2.0 major release

  • fix FIFO overruns on the BMI088 IMU
  • fix plane avoidance behaviour when in AvoidADSB mode
  • disable fatal exceptions on DMA errors on STM32
  • changed quadplane weathervaning to make pitch input optional for nose-in and tail-in
  • increased default scripting heap size on F7/H7 to 100k
  • added ICM42688 option on MatekH743
  • added ICM4xxxx option on QiotekZealotH743
  • rename INS_NOTCH parameters to INS_HNTC2
  • added Q_OPTION for RTL on failsafe in Q modes, for ship operation
  • disabled setting of highest airspeed when disarmed
  • fixed init of file descriptor in logging
  • cope with gaps in log listing, and reduce impact of log listing on EKF and ESCs
  • avoided repeated message on “failed to detach from pin” for RPM
  • improved error messages on GPIO pin configuration conflict
  • use narrower bitwidths for dshot, giving more accurate timing
  • added MatekF765-Wing-bdshot target
  • fixed use of DO_SET_SERVO with SERVOn_FUNCTION=0
  • several improvements to SPRacingH7 support

Happy flying!


Hello @tridge ,

I woul like to call your attention to an issue regarding the airspeed sensor that is not working in this beta releases.


thanks, I’ve replied on your original post


If I start the autotune process with autotune mode I can tune roll, elev and YAW with no problem. But if I start autotune with RCx=107 I only get roll and elev to tune, I never get pids for YAW.

This is a mistake? What are the differences between autotune mode and the new fixed wing autotune?

Thank you


I would like to know if it is intented to add the Precision Landing using an IR-Lock beacon for VTOLS.

Is the any intention to add this functionallity to futures Plane versions?

Thank you so much,

Eduard Miralles

1 Like

yes, I would like to add that in the future. It isn’t in 4.2, but we may get it for 4.3. We will need people to help test it.

Looks like the pre-arm checks didn’t prevent arming before the EKF was ready.

I replied in that thread

normal fixed wing autotune does not tune YAW PIDs. You can make it tune YAW PIDs, but only if you set it up to use the yaw rate controller in ACRO mode first.
You would need to set an ACRO_YAW_RATE value, and also set YAW_RATE_ENABLE=1.
Tuning of yaw PIDs like this is meant for automatic aerobatics or ACRO mode, not for normal fixed wing flight


good to hear that! My team and I can help in doing the tests! How can we get in touch?

Thank you,

Eduard Miralles

I am aware of the need to enable the YAW controller. In my case I tried it with ACRO_YAW_RATE=90 and YAW_RATE_ENABLE=1.

Precisely because of this I was able to do the YAW autotune in autotune mode. The question is why is it not possible to get PIDS from YAW via RCx=107 (new fixed wing autotune)?

The precision landing will be the feature I’ve been waiting for. Count me in for testing

because the tuning is only active when the rate PID is active. You could do it in ACRO mode (although I haven’t tried that!) or when doing an aerobatic script, but we don’t yet have the option to use the yaw rate PID in normal flight. I think we should add an option to do that.
sorry for misunderstanding your question the first time!

There is nothing to forgive and much to be thankful for the enormous work you do, and for “taking time” to respond to messages.