Copter-4.2.2 has been released and should appear as the stable version in the ground stations (MP, QGC) within the next few hours. The .apj file can also be directly downloaded from firmware.ardupilot.org.
The changes vs 4.2.1 are in the Release Notes and also copied below.
MambaH743v4 and MambaF405 MK4 autopilot support
Second full harmonic notches available (see INS_HNTC2_ parameters)
UAVCAN memory usage reduced (see CAN_Dn_UC_POOL parameter to control DroneCAN pool size)
VTOL QuikTune lua script added
Watchdog (caused by hardfault) saves crash dump logs to SD card
Bug fixes
a) Circle mode stops below altitude fence
b) CRSF protection against watchdog on bad frames
c) CRSF reset in flight handled
d) FFT init watchdog fix when ARMING_REQUIRE=0 (not actually possible on Copter)
e) OSD flight modes menu includes newer flight modes
f) Param download (via MAVFTP) fixed for params with overlapping names
g) PWM rangefinder bug fix and added SCALING parameter support
h) Replay bug fix when EK3_SRCs changed
i) SERIALx_OPTION fix when “Don’t forward mavlink to/from” selected (resolves MAVLink gimbal detection)
j) TradHeli Autotune fix which could cause incorrect gains to be loaded
k) VL53L1X rangefinder preserves addresses
Thanks as always to our beta testers for giving this a try before we released.
Could you please clarify how the first and the second harmonic notches interact?
Like, does it make sense to configure the first notch to use bidirectional DShot and the second one to use in-flight FFT? Will the second one, in this case, try to suppress the vibrations not caught by the first one?
I just updated a Matek F405-Std and a F405-WSE to 4.2.2. The WSE had no issues. The Std however…
Albeit a beater of an old DJI450, the F405-Std is flying in a fully functional quad. I did the update from 4.2.1 and decided to re-do accel calibrations and compass calibrations just to clean up a few things. During the attempt to do the compass calibration I got the error “Cannot start Compass Thread”.
It was a while I was trying to sort that out I noticed that the HUD on MP and Yaapu were both turned 90 degrees. (I would pitch the quad nose down, but the HUD would would show a roll) I attempted the Accelerometer calibrations, using two different laptops, running two different OS, both with the latest MP Beta. Nothing changed, the HUD was always a 1/4 turn off. The FC is mounted in the normal orientation, and only normal calibrations have been done prior. I even tried to load the offsets from previous log files to see if that would fix or at least change the situation. Nothing worked.
I ended up flashing the board to Plane, and re-flashing ArduCopter 4.2.2. Immediately on plane the HUD was moving in the correct direction, and once I re-flashed AC4.2.2 it all worked again. I reloaded my parameters (except the calibrations), and redid the calibrations (Accel and compass). Bench tests all look good and the HUD is working fine.
Don’t know what happened but I’ll just put it out there just in case.
They are applied in order, but any input that guides application is always pre-filter - so FFT will still apply to the main noise peaks and will be trying to squash noise already addressed by the ESC notches.
I performed two flights with 4.2.2. on Cube black powered S1000+ octocopter today. No problems occured. Subjectively, the drone looks more stable than ever before.
@andyp1per i have same problem as in 4.2.1-rc4. Racerstar rev35 with bluejay firmware for bdshot. On 4.0 everything working. But in 4.2.1 and 4.2.2. one ESC not init.
i try:
SERVO_DSHOT_RATE 2
SERVO_DSHOT_ESC 0 1 2 not help.
SERVO_BLH_MASK 0 1 2 3
SERVO_BLH_AUTO 1
SERVO_BLH_OTYPE 5
SERVO_BLH_BDMASK 0 1 2 3
If you can move the rangefinder to use the RNGFND1_ parameters then then pre-arm check should pass. I’m sure you know but just in case, use of optical flow requires a rangefinder.
Ya, experience once bad experience, drone climbs endlessly and hit ceiling. That is why I do not dare to arm and fly with such a rangefinder prearm warning. I do see the Rangefinder2 under Quick UI showing the correct cm.
ok, so there is another rangefinder besides the Hereflow’s rangefinder right? The Hereflow rangefinder does not need to be RNGFND1_… so set the RNGFND1_TYPE to match the othere (non-Hereflow) rangefinder.
The vehicle shouldn’t fly up endlessly unless an analog rangefinder is being used. With other rangefinders we should be able to detect once the rangefinder is out of range. If you’ve got a link and/or a log file for that endless climb could you provide a link to it?
@rmackay9
Thanks, works! I moved all to RNGFND1_xx, do not enable the Hereflow onboard lidar. Rangefinder preArm check enabled and no warning. took off both outdoor and indoor Loiter mode is within expected behaviour and without an external GPS installed.
thank you for the guidance and patience.
Could it be that no Range finder in 1 caused the bouncing flight I had with the super flat indoor surface with SURFTRAK_MODE=1, just curious? I may have to plan time to do a repeat test.
I have concluded that it is not due to skipping of RNGFND1, SURFTRAK_MODE=1 on our super flat blue surface not tracking well.
I upgraded to 4.2.2 and noticed that in status window, mag_ofs_x, y & z are shown as zero. Recaliberated the compass twice but still show zero when connected.
