Copter-4.3.3-rc1 has been released for beta testing and can be installed using MP or QGC’s “beta firmwares” link or it can be manually downloaded from firmware.ardupilot.org.
The changes vs 4.3.2 are in the ReleaseNotes and copied below.
Autopilot related changes
a) AIRLink LTE module enable pin and HEAT_ params added
b) CUAV Nora/Nora+ bdshot firmware (allows Bi-directional DShot)
c) CubeOrange, CubeYellow gets fast reset of ICM20602
d) MambaH743v2 with dual ICM42688 supported
e) PixPilot-V6 support
Attitude and Navigation controllers use real-time dt (better handles variable or slow main loop)
MAVFTP speed improvement including faster param download
Bug fixes
a) Analog rangefinder GPIO pin arming check fixed
b) Arming check of AHRS/EKF vs GPS location disabled if GPS disabled
c) CRSF gets RC_OPTIONS for ELRS baudrate to avoid RC failsafes
d) Null pointer checks avoid watchdog when out of memory
e) Position Controller limit handling improved to avoid overshooting and hard landings
f) Position Controller internal error after 70min of flight fixed
g) PSC_ANGLE_MAX param reduction causing WPNAV_ACCEL to be set too low fixed
h) Servo gimbal yaw jump to opposite side fixed
i) Siyi A8 gimbal driver’s record video feature fixed
j) SToRM32 serial gimbal driver actual angle reporting fixed (pitch and yaw angle signs were reversed)
k) Takeoff in Auto, Guided fixed when target altitude is current altitude
l) Takeoff in Auto handles baro drift before takeoff
m) Takeoff twitch due to velocity integrator init bug fixed
The most critical fix is “4d) Null pointer checks avoid watchdog when out of memory” although we are not aware of any user crashes caused by this. This problem is more likely to occur on boards with less memory (e.g. F4, F7 CPUs) and the vehicle would suddenly tumble and crash when a feature requiring more memory was invoked. A watchdog warning would also appear the next time the board was booted up.
There are also many takeoff and position controller improvements including the ability to handle boards running low on CPU (e.g. main loop is running below 400hz).
Be aware that in testing 4l (barometer drift before takeoff), I have confirmed that the problem is still present in 4.3.3-rc1. While not consistent, allowing the aircraft to sit for an arbitrary amount of time (in testing, typically 4-5 minutes) while in AUTO (but not armed) and then commanding a takeoff by arming (without switching flight modes) can result in navigation starting immediately after motor spoolup, typically leading to dynamic rollover. Note that the GCS altimeter does not display drift sufficient to produce the observed behavior (i.e. +3 ft., just before arming, but a 10 ft. target takeoff height - one would still expect a 7 ft. climb before heading for the next waypoint.)
I tested today 4.3.3 RC1 on small 3" copter sub 250 gr (FC Omnibus F4 2s Liion powered) and I didn’t find any problems.
Tested: stabilize, althold, loiter, optical flowhold, RTL, Smart RTL, Circle.
Hi all the fantastic people of Ardupilot. today I tested my 250 gram quad and have noticed that auto Disarm is not working after a landing. I also noticed right stick arming feels off.
Note: I talked to Andrew and he said arming right rudder was ok. So I think i will move to 4.3.3-Rc3.
Thanks for the report. There haven’t been any changes in the code related to the land detector and auto disarm so I think the issue must be environmental. The only other thing to be careful of is if you’re arming from a switch. I think the RC auxiliary switch options including “AirMode” may disable the landing detector.
Where can I check that the conversion process for firmware upgrade?
I just checked through some logs and RC7_OPTION,41 changed to 154 and I had to set it back to 153 after the firmware upgrade.
41 ArmDisarm (4.1 and lower)
to
153 ArmDisarm (4.2 and higher)
and not
154 ArmDisarm with AirMode (4.2 and higher)
Hi Randy, Uploaded curent ArduCopter V4.3.3-rc1 (22d89f59) still does not auto disarm. I have the quads twin and will try to reproduce. The quad just sits and spins after a flight.
Sorry ArduCopter V4.4.0-dev (ccd700a9)
OK, I don’t want to create work for you but if you could fly it with the beta and then again with an older firmware (4.3.2 stable or even 4.2) and provide logs for both that might help us figure out the difference.
It looks like the parameter conversion for “41” (aka “ArmDisarm”) is done as a special case here and it’s perhaps run every time the vehicle is powered on.
It looks like @iampete is the one who knows about this.
Hi All,
I think I may have a log of a file that crashed due to this issue mentioned (however I was running an H7 CPU)
Attached are the logs of the crash and post-crash. (version 4.3.2)
My questions:
Can you confirm this is the same issue mentioned above that is fixed in 4.3.3-rc1?
What is a reasonable cpu load?
I noticed cpu load changes sometimes when the vehicle maneuvers aggressively. However on some occations I noticed a cpu load decrease after about a minute airborne.
Are these normal? Do you have insight to what’s going on? What’s the best way to break the CPU load to different tasks/enabled features?
For those following, and notice their Arming channel option changed from 41 (ArmDisarm) to 154 (ArmDisarm with AirMode) during firmware upgrade…
I believe @iampete has explained to me that this is to preserve previous (undocumented) behaviour.
You can manually set your arming channel option to 153 , but having it at 154 shouldnt make any difference unless you use Acro mode (or maybe zero throttle in Stabilise mode)
