Plane 4.1.0 beta

I use BLHeli32 Rev32.7 and it supports Dshot programming commands from Rev32.3

I noticed a small bug, but I don’t know how long it’s been there, since this is the first time I’ve played around with the “Training” mode.
You can’t arm in training mode because RC1/RC2 (roll/pitch) is incorrectly assumed to be non-neutral, even if both inputs are at neutral.
This is not a big deal, since you can arm in any other mode.


I’ve just released plane 4.1.0beta3. This is a minor update over the 4.0.1beta2 release. It has a few important fixes for beta testers:

  • sync with copter 4.1.0beta5
  • added QRTL always option in Q_RTL_MODE
  • added more modes to USE_REV_THRUST parameter
  • added QioTekZealonH743 board type
  • added EKF3 protections for variance collapse
  • added PiccoloCAN servo support
  • improved VTOL position control a long distance from home
  • fixed handling of 180 degree longitude date-line crossing
  • fixed logged after forced arm
  • fixed DShot with quadplane motor test
  • adjusted autotune handling of target filter
  • adjusted default roll/pitch PID filters

Please report all test results, and happy flying!

2 Likes

here filters after update.
image
should i change they to

flew on beta3 fw on binary 1200. Try autotune with stock fillters (10 10 10)
https://1drv.ms/u/s!AuFPVI_eDaZbhbxfgw0lg3jzjYCEew?e=b0fE19
I think D still too high after autotune.

1 Like

they will only change if you had never set them. If they have been set by the user then they retain the set values.
The new defaults are:
FLTT = 3
FLTE = 0
FLTD = 12
if you set those values for both RLL_RATE and PTCH_RATE_ then you’ll have the defaults again

yes, I agree. The problem is that the oscillation detection code is not detecting the oscillation at these small amplitudes.
I’d be interested in the results if you set RLL_RATE_FLTD=0 and RLL_RATE_FLTE=0 so we regain as much phase margin as possible on the D and P PID elements. If we still get that oscillation and can’t detect it then we may need to revisit the SlewLimiter code to change how oscillation is detected.
Thanks for your patience on this - it may take several more flights to really narrow down what is happening.

1 Like

ok, thanks, try this settings in next fly

1 Like

Below are my attempts to make auto-tuning on AR Wing Pro. The result is not very good, after tuning there are fluctuations at low speed.

https://1drv.ms/u/s!AgyvhCRrlh2RmWG9zT2SkyHZbjAl?e=Dp75Jf
https://1drv.ms/u/s!AgyvhCRrlh2RmWAFWbdaK9OaQisV?e=NjjZHF

I see you’ve already tuned the SMAX down to 140. The oscillations seem worse on pitch, so maybe try PTCH_RATE_SMAX at 135 or 130? The other thing that helped my tune (AR900) was to increase the AUTOTUNE_LEVEL to 7.

ArduPlane V4.1.0dev (40ec8c72)

Dragon V2

After the autotune swing on the roll axle.

log
https://drive.google.com/file/d/1aOlpDAU_FUBby1BPEIH5XP7qEVLtp965/view?usp=sharing

dvr video https://youtu.be/Iw40L__SSK4

greeting schachti

I’ve flown 4 different aircraft on 4.1.0 Beta 3, and so far, MOSTLY good. First complaint is that BLHeli ESC telemetry sometimes takes SEVERAL reboots for the telemetry feedback to correctly initialize. I only use the ESC’s for battery monitoring, so it’s important that they work every boot.

My secondary complaint was not having reverse thrust in FBWA due to the USE_REV_THRUST parameter update and challenge setting that bitmask (Had to beta update Mission Planner).

I think the navigation controller may have gone through an update as I used to turn NAV_L1_Period to about 9, but that caused oscillations using this firmware. 13 works about right, and now the plane turns sharp even with higher NAV_L1_Periods. That could be a total coincidence, but I don’t think anything changed except the firmware.

Another thing I remember noticing; going from manual to FBWA after sitting on the bench for quite a few minutes, I thought I saw the servos jump once quite a bit. I’m not sure if some I-term buildup was happening or what, but it was slightly unusual.

Last, but not least, I received internal errors on both of my survey missions, and even though it read “failsafe” while in the air, it continued the mission: https://github.com/ArduPilot/ardupilot/issues/18046

Hi Nathan, This was my solution to the internal error…Mine appeared to have been triggered by the camera settings (servo and relay inputs) even after I removed all the servo inputs I still had the internal error that was finally fixed by changing the relay default to 1.

My RELAY_DEFAULT was 1, and changing to 0 did not help.

Just had a crash during transition to forward flight on a quadplane 4+1 in 4.1.0beta2. Loss of pitch and roll control. Aircraft has at least 5 hours on it with 4.1.0beta2.

Bin log.

Very similar to the setup that had this happen, but that was on 4.1.0beta1

can you post the log of the successful flight just prior to this one on the same aircraft?

Thanks for looking into this @tridge!

Nominally identical aircraft, same day, 4.1.0beta1. Log

Same aircraft, different day. Much of the FBWA flight was using RC overrides from a companion computer. Largest number log in this folder is the flight immediately before the mishap flight. Log

how much throw do you have on the elevator? I’m wondering if it is too much throw and you are stalling the elevator.
Basically the crash log makes no sense. The control surface and motor output values all look good. It could be a failure on the rear VTOL motors when the voltage drops as the fwd motor kicks in, but I don’t see a current drop that would point at that.
The current draw is a bit higher than in the previous log on the same aircraft I looked at, but not by a huge margin.


I’ve just released ArduPilot Plane 4.1.0beta4. This is a large beta update, with significant changes over beta3.

The biggest changes are in EKF3, with a move to double precision floating point calculations on MCUs that support it. This also includes changes to support very long distance flight (flights around the world have been tested in simulation). Previously the EKF would start getting some degree of error at a few hundred kilometers, and would fail completely at 1000km from the startup location.

The beta also includes major changes to the fixed wing autotune based on the great feedback and logs from users running the earlier beta releases. You can watch a video showing the changes in autotune here:

I would really appreciate logs from anyone still having issues with autotune with beta4.

Other changes include:

  • added MAN_EXPO_* parameters for input expos in MANUAL, TRAINING and ACRO modes without having to set them up in your transmitter
  • added ONESHOT_MASK for oneshot output on control surfaces
  • GPS-for-yaw enhancements including using position and yaw from different GPSs
  • major improvements to EKF3 stability
  • BLHeli fix that could cause failure to boot
  • CRSF message spamming and firmware string length fixed
  • Display re-enabled on 1MB boards
  • DShot always sends 0 when disarmed (protects against motors spin while disarmed due to misconfiguration)
  • DShot fix that could cause main loop jitter
  • DShot buzzer tone disabled during motor test to remove bad interation
  • MatekF405-bdshot NeoPixel LEDs re-enabled on PWM5
  • Serial port performance improvements using FIFO on H7 boards

Please report all test results and happy flying!

5 Likes

Thanks @tridge for the great work a friend was getting oscillation in pitch after auto tuning an AR Wing Pro. We will give this a go I have mine ready for a post lockdown maiden!

1 Like